Subject: [rtcweb] authenticating against IMS HSS/HLR

From: Cameron Byrne <[email-masked]>
Date: Tue, 29 May 2012 10:02:42 -0700

Is there yet a pointer on how a SIM / IMS based identity will work
with the webRTC web server for authentication?

I think the obvious approach is for the SIM secret key to be bound to
a username / password on the web server, and the web server proxies
the authentication and registration into IMS (if you give me the right
username credentials via the web, i will register you into IMS with
the secret key), but that requires the undesirable step of exposing
the SIM secret key to the web server or someplace outside the HSS/HLR
for binding with the username password.

Thoughts?  Pointers?

Thanks,

CB

---

From: Martin Thomson <[email-masked]>
Date: Tue, 29 May 2012 10:17:00 -0700

That's assuming that you want to authenticate as a mobile identity.
Why would it not be sufficient to authenticate as a linked identity?

That is, I am "[email-masked]" and some of my calls originate
or terminate at
"+1-234-555-6789".

Can you expand on your use case a little?

On 29 May 2012 10:02, Cameron Byrne <[email-masked]> wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 29 May 2012 10:22:07 -0700

> That is, I am "[email-masked]" and some of my calls originate

Basic use case is exposing mobile operator IMS services via webrtc.

Such that webrtc is an IMS clients of sorts and the various IMS
services are exposed via webrtc just as they are exposed to an IMS
client (voice, video, presence, IM, ...).

Using the mobile identity to register into the IMS domain seems to be
the simplest fit if authentication is possible. From a deployment and
operational ease perspective, it sure would be nice if nothing had to
change in the IMS cloud and webrtc was just a proxy / client for
accessing the IMS services.

CB

---

From: Martin Thomson <[email-masked]>
Date: Tue, 29 May 2012 10:26:30 -0700

> accessing the IMS services.

How your clients authenticate with your service is largely not a
problem for this working group...

That said, if you want to authenticate as an IMS UE, then you need to
be able to offer the credentials that a UE would offer.  So why not
proxy the authentication requests too?  Then the server doesn't need
to store credentials.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 29 May 2012 13:29:03 -0400

To answer your question directly, I don't think there's a current document.

However, ISTM that the HSS/HLR could just act as an Identity Provider [1], for example by layering BrowserID [2] on top of the IMS:
-- UE generates key pair locally
-- UE authenticates to HSS/HLR
-- UE presents public key to HSS/HLR
-- HSS/HLR provides a certificate containing that public key
-- UE presents that certificate to the remote party
-- Remote party validates certificate under HSS/HLR public key

The main question would then be what identifiers a relying party would allow an HSS/HLR to vouch for.  For SIP URIs, there's no problem, because the domain of the HSS/HLR would be clear (the domain part of the URI).  But for telephone numbers, the HSS/HLR would have to be a "third party" IdP, which is problematic [3].

Hope this helps,
--Richard

[1] <http://tools.ietf.org/html/draft-rescorla-rtcweb-generic-idp-00>
[2] <http://tools.ietf.org/html/draft-rescorla-rtcweb-generic-idp-00#section-5.5.1>
[3] Slide 5 of <http://tools.ietf.org/agenda/83/slides/slides-83-rtcweb-2.pdf>

---

From: Igor Faynberg <[email-masked]>
Date: Tue, 29 May 2012 14:16:09 -0400

Cameron,

Indeed, there is a lot of interesting work done in this field. (A few 
thousand messages back you will find some postings on the subject, 
including mine.)  A few references will follow, but first--the problem.

The problem is the access to "the SIM secret key."  The latter is 
unavailable by design: all ISIM operations are performed by the card. 
IMS itself builds on the AKA protocol, which establishes the necessary 
keys. From there, 3GPP recommends bootstrapping using the Generic 
Bootstrapping Architecture. 3GPP defines this in detail in 3GPP TS 33.220.

3GPP has a technical report, TR 33.924, which specifies an 
implementation of OpenID with GBA. One problem here is  client 
deployment.  Until GB function is deployed in the Client, it is, of 
course, impossible to use any solution that depends on it.

Hence the alternative solution: to use AKA. My colleagues and I have 
described a way to do so in a Bell Labs Technical Journal paper 
http://onlinelibrary.wiley.com/doi/10.1002/bltj.20426/abstract. 
Subsequently, a method to implement OpenID/AKA interworking has been 
specified by ITU-T in   Recommendation Y.2722 NGN Identity Management 
Mechanisms. (All ITU-T Recommendations as well as 3GPP documents are 
available on their respective sites.)

But the latter solution is still a non-solution as long as there is no 
client API for interactions with the SIM card. And this was the 
conclusion of a discussion on this list a while ago...

We need either such an API or GBA deployment to progress.

Igor

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 29 May 2012 22:43:51 +0200

> with the webRTC web server for authentication?
Is there a standard Javascript API defined for access to SIM-based 
identity services?

Once that exists, it seems to be all a Small Matter Of Javascript.
As long as that does not exist, we seem to be building without a foundation.

---

From: Igor Faynberg <[email-masked]>
Date: Tue, 29 May 2012 17:16:51 -0400

Right, and I would not even require that it be Javascript.  Say, it is 
device-specific so only the browser can use it.

Igor

---

From: <[email-masked]>
Date: Wed, 30 May 2012 09:14:33 +0000

Hi,

RFC 4169 defines digest-AKA, which is how SIM-card based AKA authentication is used within the context of HTTP digest. It could be used for user authentication for HTTP after TLS has been setup. 

There are some platforms that enable SIM access to at least some special applications. Presumably browser could be one of them and a Javascript API could be also exposed to apps if needed.

The web server would need a Radius interface to operator HLR/HSS.

I don't know if anything else would be needed.

Markus

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of ext Cameron Byrne
>Sent: 29 May, 2012 20:03
>To: [email-masked]
>Subject: [rtcweb] authenticating against IMS HSS/HLR
>
>Is there yet a pointer on how a SIM / IMS based identity will work with the
>webRTC web server for authentication?
>
>I think the obvious approach is for the SIM secret key to be bound to a
>username / password on the web server, and the web server proxies the
>authentication and registration into IMS (if you give me the right username
>credentials via the web, i will register you into IMS with the secret key), but
>that requires the undesirable step of exposing the SIM secret key to the web
>server or someplace outside the HSS/HLR for binding with the username
>password.
>
>Thoughts?  Pointers?
>
>Thanks,
>
>CB

---

From: Igor Faynberg <[email-masked]>
Date: Wed, 30 May 2012 10:40:03 -0400

On 5/30/2012 5:14 AM, [email-masked] wrote:
> ...

Could you please supply a reference to any such platform?
> The web server would need a Radius interface to operator HLR/HSS.

Actually, it would have been Diameter, but in reality the web server 
cannot (and should not) talk to HSS directly; it will talk to an entity 
that maps the IMS identity to OpenID or whatever other identity is used.

Igor

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 30 May 2012 08:01:11 -0700

On Tue, May 29, 2012 at 11:16 AM, Igor Faynberg
<[email-masked]> wrote:
> thousand messages back you will find some postings on the subject, including
> mine.)  A few references will follow, but first--the problem.
>
> unavailable by design: all ISIM operations are performed by the card. IMS
> itself builds on the AKA protocol, which establishes the necessary keys.
> From there, 3GPP recommends bootstrapping using the Generic Bootstrapping
> Architecture. 3GPP defines this in detail in 3GPP TS 33.220.
>
> 3GPP has a technical report, TR 33.924, which specifies an implementation of
> OpenID with GBA. One problem here is  client deployment.  Until GB function
> is deployed in the Client, it is, of course, impossible to use any solution
> that depends on it.
>

Thanks, this is probably the pointer i need.

GBA is already available to me and we have it deployed in the network
and on devices.  I will need to do more reading on this and how it all
really works.  The goal is that the IMS service is completely
abstracted from the UE and the IMS services and associated identities
can be fully instantiated on any devices that has a WebRTC browser
(smart tv, wifi-only tablet, refrigerator...)

Cameron

> client API for interactions with the SIM card. And this was the conclusion
> of a discussion on this list a while ago...
>