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

From: "Liess, Laura" <[email-masked]>
Date: Sun, 20 Jul 2003 18:43:39 +0200

Draft-sterman-aaa-sip-01.txt for authentication and draft-schulzrinne-accounting-sip-01.txt for accounting would be fine.                    
Thanks, Laura

>-----Ursprungliche Nachricht-----
>Von: Bernard Aboba [mailto:[email-masked]]
>Gesendet: Sonntag, 20. Juli 2003 05:37
>An: Liess, Laura
>Cc: [email-masked]; [email-masked]; Dumler, Alexander; Wolff,
>Christian
>Betreff: Re: AW: [Sipping] FYI: RADIUS & SIP
>
>
>Is there some particular set of draft(s) that you are 
>advocating work on?
>
>On Fri, 18 Jul 2003, Liess, Laura wrote:
>
>> 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)
>

_______________________________________________
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: "McCandless, Kevin" <[email-masked]>
Date: Tue, 29 Jul 2003 07:39:08 -0700

This thread seems to rehash an old issue and that was DIAMETER or RADIUS for SIP authentication.  As I remember the discussion and tentative recommendation is that SIP would adopt DIAMETER as the  standard for AAA functionality and that DIAMETER servers would interoperate with RADIUS servers.  As I understood it, the companies that have the embedded base of RADIUS servers could continue to use them for SIP 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
> 
> 
> >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
> >
> >

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 29 Jul 2003 10:31:33 -0500

> Is this sufficient or is something else needed too?

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 complaints?

Thanks, Henry

> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Tuesday, July 29, 2003 12:29 AM
> To: Henry Sinnreich
> Cc: [email-masked]; [email-masked]; 'Dumler, 
> Alexander'; 'Liess, Laura'; 'Wolff, Christian'
> Subject: RE: AW: [Sipping] FYI: RADIUS & SIP
> 
> > 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: "Beck01, Wolfgang" <[email-masked]>
Date: Thu, 31 Jul 2003 09:00:03 +0200

> 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 and 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.

Having something like SIM cards in SIP phones is a good idea.
However, the GSM SIM card security mechanisms are obscure and
have been broken. The flaws are not a show stopper for GSM,
but I doubt that is a good idea to reuse broken algorithms.

> Plus, SIM-based authentication could be used as a bootstrap
> mechanism for X.509 certficate distribution and therefore for
> TLS mutual authentication.
> 
I support this, but I fear ISIMs will be cheaper as they are
already standardized and will be promoted by the UMTS providers.

> 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
you mean informational RfC 3310?

--
Wolfgang Beck
T-Systems Nova GmbH

---

From: Michael Haberler <[email-masked]>
Date: Thu, 31 Jul 2003 13:07:56 +0200

>However, the GSM SIM card security mechanisms are obscure and

The GSM SIM authentication method is plain CHAP, which is not obsure at 
all, as is the spec.

The *sample algorithm* used to compute response and session key in an early 
spec (COMP128-1) is indeed "obsure" and has been broken.

However, the algorithm is an operator's choice, and many operators have 
opted to use different algoríthms which have *not* been broken.

>but I doubt that is a good idea to reuse broken algorithms.

The right of any operator to shoot themselves in the foot is unlimited, but 
there's no requirement in the spec to do so. Use any recent algorithm and 
you're fine, within the limits of single-sided CHAP.

>already standardized and will be promoted by the UMTS providers.

The point isnt about cost of an ISIM vs classic SIM, it is about the 
authentication centers and billing capabilites of *existing* mobile 
operators. Existing or second SIM cards ´could be used for combined SIP/LAN 
access authentication say as a second line service. The same sets could be 
used as ISP VoIP service terminals. The hardware isnt quite there yet, and 
the operators might not understand this fully yet, but the market window is 
wide open.

Just because somebody invents the ISIM or USIM, that doesnt mean the whole 
lot of GSM operators will run out and upgrade to UMTS authentication 
capabilities. In fact both UMTS operators in Austria have opted to stay 
with GSM SIM authentication! There goes your ISIM method. The WLAN folks 
have figured that out and came up with EAP/SIM - because if the would 
insist to use I/USIMs exlusively they wouldnt sell a single piece of 
hardware for a loooong time.

-Michael Haberler

---

From: "Liess, Laura" <[email-masked]>
Date: Thu, 31 Jul 2003 16:41:04 +0200

I agree with Jonathan. Support for prepaid calling seems to me a very good idea.  
Laura

Laura Liess
T-Systems/Deutsche Telekom Group
Am Kavalleriesand 3
64295 Darmstadt

>Von: Jonathan Rosenberg [mailto:[email-masked]]
>Gesendet: Dienstag, 29. Juli 2003 20:13
>An: Bernard Aboba
>Cc: Liess, Laura; [email-masked]; [email-masked]; Dumler,
>Alexander; Wolff, Christian
>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-si
>p-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:
>
>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
>

---

From: Michael Haberler <[email-masked]>
Date: Thu, 31 Jul 2003 19:28:07 +0200

At 14:45 31.07.2003 +0200, Beck01, Wolfgang wrote:

>Thanks for the clarification. Coming back to the original question, a
>RADIUS server would have to support several challenge/response schemes:
>- CHAP (available in today's RADIUS servers, but not in today's SIP phones)
>- HTTP Digest (Sterman draft, available in some RADIUS servers and most 
>SIP phones)
>- the GSM SIM A3 algorithm du jour
>- 3GPP ISIM AKA
>if the provider does not have an alternative GSM authentication
>infrastructure.

HTTP Digest is largely CHAP as is GSM SIM, and with a minor modification 
the Sterman draft can cover GSM authentication in a basic configuration as 
well. For better security properties like in EAP/SIM we would need a 
separate authentication method, as this cant be easily retrofitted into 
HTTP digest and HTTP EAP did not make it.

The difference is in challenge computation - the Sterman draft locally 
computes a challenge, challenges the client, receives the response and 
sense challenge and response to the RADIUS server for authentication.

The way GSM authentication works is that the Authentication Center produces 
"triplets" (tuples of precomputed challenge, matching response and session 
key) for a given IMSI. This triplet can be gatewayed to a RADIUS server 
through an SS7 MAP gateway (this is what the EAP-SIM WLAN RADIUS 
infrastructure does). So the Radius server must first fetch a triplet after 
he has received the authentication user id (the IMSI, International Mobile 
Subscriber Identity), and use the challenge from that triplet. So there's 
some RADIUS work, and more with HTTP AKA.

We have currently a project with iptel.org to implement a prototype to 
study basic feasability of SIP client authentication with SIM cards.

This thread was about the question how existing RADIUS infrastructures can
>be extended to support SIP. Your proposal is about the question how SIP
>should be extended to be able to reuse a existing GSM authentication
>infrastructures. This is reasonable for a mobile operator but not for an
>ISP.

I believe the GSM authentication method is one of our few viable options to 
bootstrap better stuff, like X.509 certificates, off it. For instance, in 
an authenticated context one could download a certificate over the air into 
the card, or even SIM Toolkit application, or client configuration data. 
Once you have a certificate you use it with TLS.

This would give mobile operators who want it a second line service, and an 
ISP the choice to authenticate himself against his own Radius+database, or 
sell the customers to a mobile operator - if there is a common standard 
without user base migration.

I dont believe a "standalone" ISP-only authentication smart card method 
will get off the ground easily.

>However, using smart cards (SIM, ISIM, Cryptoflex etc) makes sense for ISPs,
>too. It's easier to tell the customer: "insert this card here" instead of
>saying: "go to menu x, item y and enter a password longer than 5 characters
>with at least 2 numerics, don't choose your aunt's surname and change it
>every 8 weeks ...". Interoperability with existing GSM is in this case not
>as important as it is for mobile operators.

This is psychologically very important - you dont have to explain what a 
SIM card is - it is deja vu for the consumer. You're just distributing an 
"Internet SIM card", which has a number and an account associated with it.

Technically I would agree on the interoperability, but not on the market 
devlopment aspect. Mobile operators are also wonderful billing and 
authentication machines.

-Micahel Haberler

---

From: Michael Haberler <[email-masked]>
Date: Thu, 31 Jul 2003 19:37:18 +0200

At 11:05 31.07.2003 -0400, Gunn, Janet wrote:

>The SIM card in my GSM phone doesn't have a PIN associated with it.  Or if

It does, or it aint a GSM SIM card, however asking for the PIN code may be 
turned off. See http://www.ttfn.net/techno/smartcards/gsm11-11.pdf for the 
basics. I've collected some introductory material at 
http://www.mah.priv.at/siptrust/doit/sim.html .

>I think the model would be a "SIM card" that you keep in your wallet, like a
>credit card, and use on whatever "phone" you want.  And/or have multiple SIM
>cards- one/some that you leave in your "regular phone(s)", and one you keep
>in your wallet.

I was assuming a personal phone user context, like a WiFi SIP handset, with 
a SIM card permanently inserted into it - much like a cellular.

But it is not uncommon to find PBX extensions in large organizations which 
use smart cards inserted in the phone for accounting purposes. I dont think 
this is very appealing.

-Michael Haberler

>From: Henning Schulzrinne [mailto:[email-masked]]
>Sent: Thursday, July 31, 2003 10:39 AM
>To: Beck01, Wolfgang
>Cc: [email-masked]
>Subject: Re: AW: [Sipping] FYI: RADIUS & SIP
>
>
>
>
>Don't SIM cards also have PINs? Thus, you still have to tell the
>customer "don't choose the last four digits of your social security
>number or 1234"... Obviously, requiring both "something you have" and
>"something you know" is more secure than jut "something you know".
>
>Also, while SIM cards work ok when kept in the cell phone, the existing
>card mechanics don't seem to work well if you want to, say, quickly use
>the phone in the meeting room. Would you need to remove and insert the
>SIM card each time? "Oops, I left the card in my office phone, I can't
>make a call from home right now."
>
>