headers
David Fuelling | 3 Mar 2010 17:33
Picon
Gravatar

[OpenID] UCI Idea: An iPhone OP (?)

Wondering what people think about using as an iPhone (or Android/etc) application as a personal OP.  

Basically, the way it would work is as follows:
  1. Go to RP, get prompted with a login form.
  2. Turn on iPhoneOP application on your iPhone.
    1. iPhone App turns on lighttpd (or some other ultra-small web server) to serve web requests from the phone and act as an OP.
    2. iPhone App then connects to a DDNS service that connects the phone's current IPV6 address to the OP domain.
    3. The iPhone is now the user's OP.
  3. User signs into the RP, which then does the OpenID dance with the OP running on the user's iphone.
  4. The user could login via the web, or optionally just get prompted on the phone that a login is occurring - the user could then accept the login and/or enter a security code (in case of a lost iPhone).
  5. User is logged-into the RP.
  6. iPhone App turns off.
Some initial thoughts I've had:
  1. Could this take us a lot closer to a user-centric identity?  Imagine if this software was built into the phone (so you didn't have to run an App to make it work).  
  2. Something like this would be interesting from a multi-auth perspective.  On the one hand, it could preclude the need for mulit-auth because a person could turn off his OP when the app isn't running (thus ensuring no RP logins without the phone....mostly -- see some security drawbacks below).  
  3. Alternatively, it could provide one multi-auth solution in that an RP could be required to get an assertion from a "regular" OP and a user-centric OP (like the iPhone) before allowing access.
Security Drawbacks (?)
  1. The user should trust his/her DDNS provider because somebody at that provider could change the IP address hooked up to the domain backing the iPhoneOP (without the knowledge of the user).  However, this is an issue with current OPs (the rogue employee problem).  Either could be mitigated with multi-auth.
_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Permalink | Reply |
headers
Peter Watkins | 3 Mar 2010 17:58
Favicon

Re: [OpenID] UCI Idea: An iPhone OP (?)


1a) Historically, consumer internet providers have not liked to
   allow customers to "run servers". TCP/80 has been largely blocked
   since Code Red in July 2001, TCP/25 blocks largely predated the SPF 
   movement; I don't know about TCP/443, but I would expect many 
   providers to block it, too. It's certainly not hard to imagine
   a cellular provider deciding that normal customers should *never*
   accept new TCP connections (What's that gonna break, FTP? Who cares?).
   Use a weird port and there's a fair chance that the RP's outbound
   firewall rules will prevent it from completing OpenID discovery.

1b) I can't see this working on typical wifi scenarios where the
   device has an IANA reserved address behind some SNAT gateway; 
   simply no good way for the Internet-based RP to initiate a 
   connection back to the micro OP. With weird ports, an intelligent 
   middle-man service could map a public middle-man port to your mobile 
   through a mobile-initiated TCP tunnel to the middle-man, but we're 
   back to RP's outbound firewall rules.

2) Avoid the dyndns trust issue by using https URLs for your micro OP.
   (Nobody should be using plain http for OP endpoints!)

3) Sounds like a better scenario for plain old https client certificates.
   Or maybe InfoCard, but good luck getting Apple to bake that support 
   into iPhone Safari.

4) iPhone: all this without background apps? How would you use iPhone
   Safari to authenticate to iPhone Micro OP if the two cannot run 
   simultaneously? I don't think you can -- Micro OP would need to
   bind to a TCP port to listen for http requests, and Safari would
   need to connect to it. If they can't run concurrently, then you
   simply cannot make that TCP connection, right?

-Peter

On Wed, Mar 03, 2010 at 11:33:43AM -0500, David Fuelling wrote:
> Wondering what people think about using as an iPhone (or Android/etc)
> application as a personal OP.
> 
> Basically, the way it would work is as follows:
> 
>    1. Go to RP, get prompted with a login form.
>    2. Turn on iPhoneOP application on your iPhone.
>       1. iPhone App turns on lighttpd (or some other ultra-small web server)
>       to serve web requests from the phone and act as an OP.
>       2. iPhone App then connects to a DDNS service that connects the
>       phone's current IPV6 address to the OP domain.
>       3. The iPhone is now the user's OP.
>    3. User signs into the RP, which then does the OpenID dance with the OP
>    running on the user's iphone.
>    4. The user could login via the web, or optionally just get prompted on
>    the phone that a login is occurring - the user could then accept the login
>    and/or enter a security code (in case of a lost iPhone).
>    5. User is logged-into the RP.
>    6. iPhone App turns off.
> 
> Some initial thoughts I've had:
> 
>    1. Could this take us a lot closer to a user-centric identity?  Imagine
>    if this software was built into the phone (so you didn't have to run an App
>    to make it work).
>    2. Something like this would be interesting from a multi-auth
>    perspective.  On the one hand, it could preclude the need for mulit-auth
>    because a person could turn off his OP when the app isn't running (thus
>    ensuring no RP logins without the phone....mostly -- see some security
>    drawbacks below).
>    3. Alternatively, it could provide one multi-auth solution in that an RP
>    could be required to get an assertion from a "regular" OP and a user-centric
>    OP (like the iPhone) before allowing access.
> 
> Security Drawbacks (?)
> 
>    1. The user should trust his/her DDNS provider because somebody at that
>    provider could change the IP address hooked up to the domain backing the
>    iPhoneOP (without the knowledge of the user).  However, this is an issue
>    with current OPs (the rogue employee problem).  Either could be mitigated
>    with multi-auth.
Permalink | Reply |
headers
David Fuelling | 3 Mar 2010 21:38
Picon
Gravatar

Re: [OpenID] UCI Idea: An iPhone OP (?)

On Wed, Mar 3, 2010 at 11:58 AM, Peter Watkins <peterw <at> tux.org> wrote:


 1b) I can't see this working on typical wifi scenarios where the
  device has an IANA reserved address behind some SNAT gateway;
  simply no good way for the Internet-based RP to initiate a
  connection back to the micro OP. With weird ports, an intelligent
  middle-man service could map a public middle-man port to your mobile
  through a mobile-initiated TCP tunnel to the middle-man, but we're
  back to RP's outbound firewall rules.


Good point about trying to run an iPhoneOP on wifi.  I guess I was thinking this would just go over the 3G network in order to avoid firewall and routing problems.  

There's a company with an iPhone App called "ServersMan" (http://serversman.com/promo/promo_ip_en.html -- now available in US and Japanese App Store) that runs a web server on the iPhone.  Using there app, you can hit a URL from a web-browser on your computer, and view files served from a webserver running on the iPhone.  This app can work over the 3G network (worked when I tested it with my phone's wifi turned off).  

 
2) Avoid the dyndns trust issue by using https URLs for your micro OP.
  (Nobody should be using plain http for OP endpoints!)


Great point!

4) iPhone: all this without background apps? How would you use iPhone
  Safari to authenticate to iPhone Micro OP if the two cannot run
  simultaneously? I don't think you can -- Micro OP would need to
  bind to a TCP port to listen for http requests, and Safari would
  need to connect to it. If they can't run concurrently, then you
  simply cannot make that TCP connection, right?


Yes, at least for iPhone this would preclude openid in mobile safari (likely -- I suppose one might be able to program around this).

I was more thinking of the instance where I'm using the web-browser on my laptop to surf, and so I could have the iPhoneOP app running for the duration of the OpenID login.

_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Permalink | Reply |
headers
SitG Admin | 3 Mar 2010 23:37

Re: [OpenID] UCI Idea: An iPhone OP (?)

>Yes, at least for iPhone this would preclude openid in mobile safari 
>(likely -- I suppose one might be able to program around this).

I'm not familiar with programming on the iPhone - is it actually 
impossible to run more than one app at once? If not, just bind the OP 
to localhost (have the apps talk to each other directly instead of 
sending *anything* over the network) when Safari needs to talk to the 
OP, and otherwise a plugin for Safari to include the OpenID app's 
libraries when acting as it? Again, not familiar with programming on 
the iPhone :)

-Shade
Permalink | Reply |
headers
Kenji Takahashi | 4 Mar 2010 03:23
Picon

Re: [OpenID] UCI Idea: An iPhone OP (?)

Similar effort by Nokia.  http://betalabs.nokia.com/apps/mobile-web-server

Kenji

David Fuelling wrote:
> On Wed, Mar 3, 2010 at 11:58 AM, Peter Watkins <peterw <at> tux.org> wrote:
>
>   
>>  1b) I can't see this working on typical wifi scenarios where the
>>   device has an IANA reserved address behind some SNAT gateway;
>>   simply no good way for the Internet-based RP to initiate a
>>   connection back to the micro OP. With weird ports, an intelligent
>>   middle-man service could map a public middle-man port to your mobile
>>   through a mobile-initiated TCP tunnel to the middle-man, but we're
>>   back to RP's outbound firewall rules.
>>
>>
>>     
> Good point about trying to run an iPhoneOP on wifi.  I guess I was thinking
> this would just go over the 3G network in order to avoid firewall and
> routing problems.
>
> There's a company with an iPhone App called "ServersMan" (
> http://serversman.com/promo/promo_ip_en.html -- now available in US and
> Japanese App Store) that runs a web server on the iPhone.  Using there app,
> you can hit a URL from a web-browser on your computer, and view files served
> from a webserver running on the iPhone.  This app can work over the 3G
> network (worked when I tested it with my phone's wifi turned off).
>
>
>
>   
>> 2) Avoid the dyndns trust issue by using https URLs for your micro OP.
>>   (Nobody should be using plain http for OP endpoints!)
>>
>>
>>     
> Great point!
>
> 4) iPhone: all this without background apps? How would you use iPhone
>   
>>   Safari to authenticate to iPhone Micro OP if the two cannot run
>>   simultaneously? I don't think you can -- Micro OP would need to
>>   bind to a TCP port to listen for http requests, and Safari would
>>   need to connect to it. If they can't run concurrently, then you
>>   simply cannot make that TCP connection, right?
>>
>>
>>     
> Yes, at least for iPhone this would preclude openid in mobile safari (likely
> -- I suppose one might be able to program around this).
>
> I was more thinking of the instance where I'm using the web-browser on my
> laptop to surf, and so I could have the iPhoneOP app running for the
> duration of the OpenID login.
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> general mailing list
> general <at> lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
>
Permalink | Reply |
headers
Joost Van Dijk | 3 Mar 2010 21:57
Picon
Picon

Re: [OpenID] UCI Idea: An iPhone OP (?)

On 3/3/10 5:58 PM, Peter Watkins wrote:
> 
> 1a) Historically, consumer internet providers have not liked to
>    allow customers to "run servers". TCP/80 has been largely blocked
>    since Code Red in July 2001, TCP/25 blocks largely predated the SPF 
>    movement; I don't know about TCP/443, but I would expect many 
>    providers to block it, too. It's certainly not hard to imagine
>    a cellular provider deciding that normal customers should *never*
>    accept new TCP connections (What's that gonna break, FTP? Who cares?).
>    Use a weird port and there's a fair chance that the RP's outbound
>    firewall rules will prevent it from completing OpenID discovery.
> 
> 1b) I can't see this working on typical wifi scenarios where the
>    device has an IANA reserved address behind some SNAT gateway; 
>    simply no good way for the Internet-based RP to initiate a 
>    connection back to the micro OP. With weird ports, an intelligent 
>    middle-man service could map a public middle-man port to your mobile 
>    through a mobile-initiated TCP tunnel to the middle-man, but we're 
>    back to RP's outbound firewall rules.
> 
> 2) Avoid the dyndns trust issue by using https URLs for your micro OP.
>    (Nobody should be using plain http for OP endpoints!)
> 
> 3) Sounds like a better scenario for plain old https client certificates.
>    Or maybe InfoCard, but good luck getting Apple to bake that support 
>    into iPhone Safari.

Speaking of client certificates, I've been looking at Mobile PKI
technology, where one can use RSA keys safely stored on a mobile phone's
SIM for authentication (and signing) purposes.

If you are interested: here's a report:

http://www.terena.org/news/community/download.php?news_id=2528

We have integrated this technology into an Identity Provider (supporting
OpenID). What is nice about this technology is that it works with *any*
phone, because the application that does the authentication/signing is
placed on the SIM instead of the phone's OS.

I must add however that this also means a SIM is required that has the
app installed (together with some memory constraints), requires
cooperation from a mobile operator (as communication is over a mobile
network instead of over the Internet), and this technology hasn't been
deployed in many countries.

Still, it is kinda cool to watch yourself being logged into an RP by
entering a 4-digit PIN on your mobile phone :-)

--
Joost van Dijk
SURFnet

> 
> 4) iPhone: all this without background apps? How would you use iPhone
>    Safari to authenticate to iPhone Micro OP if the two cannot run 
>    simultaneously? I don't think you can -- Micro OP would need to
>    bind to a TCP port to listen for http requests, and Safari would
>    need to connect to it. If they can't run concurrently, then you
>    simply cannot make that TCP connection, right?
> 
> -Peter
> 
> On Wed, Mar 03, 2010 at 11:33:43AM -0500, David Fuelling wrote:
>> Wondering what people think about using as an iPhone (or Android/etc)
>> application as a personal OP.
>>
>> Basically, the way it would work is as follows:
>>
>>    1. Go to RP, get prompted with a login form.
>>    2. Turn on iPhoneOP application on your iPhone.
>>       1. iPhone App turns on lighttpd (or some other ultra-small web server)
>>       to serve web requests from the phone and act as an OP.
>>       2. iPhone App then connects to a DDNS service that connects the
>>       phone's current IPV6 address to the OP domain.
>>       3. The iPhone is now the user's OP.
>>    3. User signs into the RP, which then does the OpenID dance with the OP
>>    running on the user's iphone.
>>    4. The user could login via the web, or optionally just get prompted on
>>    the phone that a login is occurring - the user could then accept the login
>>    and/or enter a security code (in case of a lost iPhone).
>>    5. User is logged-into the RP.
>>    6. iPhone App turns off.
>>
>> Some initial thoughts I've had:
>>
>>    1. Could this take us a lot closer to a user-centric identity?  Imagine
>>    if this software was built into the phone (so you didn't have to run an App
>>    to make it work).
>>    2. Something like this would be interesting from a multi-auth
>>    perspective.  On the one hand, it could preclude the need for mulit-auth
>>    because a person could turn off his OP when the app isn't running (thus
>>    ensuring no RP logins without the phone....mostly -- see some security
>>    drawbacks below).
>>    3. Alternatively, it could provide one multi-auth solution in that an RP
>>    could be required to get an assertion from a "regular" OP and a user-centric
>>    OP (like the iPhone) before allowing access.
>>
>> Security Drawbacks (?)
>>
>>    1. The user should trust his/her DDNS provider because somebody at that
>>    provider could change the IP address hooked up to the domain backing the
>>    iPhoneOP (without the knowledge of the user).  However, this is an issue
>>    with current OPs (the rogue employee problem).  Either could be mitigated
>>    with multi-auth.
> 
> _______________________________________________
> general mailing list
> general <at> lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
Permalink | Reply |
headers
David Fuelling | 3 Mar 2010 22:15
Picon
Gravatar

Re: [OpenID] UCI Idea: An iPhone OP (?)

Great report!!  Thanks for sharing that!

On Wed, Mar 3, 2010 at 3:57 PM, Joost Van Dijk <joost.vandijk <at> surfnet.nl> wrote:
Speaking of client certificates, I've been looking at Mobile PKI
technology, where one can use RSA keys safely stored on a mobile phone's
SIM for authentication (and signing) purposes.

If you are interested: here's a report:

http://www.terena.org/news/community/download.php?news_id=2528


_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Permalink | Reply |
headers
Paul Madsen | 3 Mar 2010 18:03
Favicon

Re: [OpenID] UCI Idea: An iPhone OP (?)

Hi David, NTT built something like you describe for SAML SSO - specifically the scenario you list below in #4

http://www.projectliberty.org/liberty/content/download/3960/26523/file/NTT-SASSO%20liberty%20case%20study.pdf

paul

On 3/3/2010 11:33 AM, David Fuelling wrote:
Wondering what people think about using as an iPhone (or Android/etc) application as a personal OP.  

Basically, the way it would work is as follows:
  1. Go to RP, get prompted with a login form.
  2. Turn on iPhoneOP application on your iPhone.
    1. iPhone App turns on lighttpd (or some other ultra-small web server) to serve web requests from the phone and act as an OP.
    2. iPhone App then connects to a DDNS service that connects the phone's current IPV6 address to the OP domain.
    3. The iPhone is now the user's OP.
  3. User signs into the RP, which then does the OpenID dance with the OP running on the user's iphone.
  4. The user could login via the web, or optionally just get prompted on the phone that a login is occurring - the user could then accept the login and/or enter a security code (in case of a lost iPhone).
  5. User is logged-into the RP.
  6. iPhone App turns off.
Some initial thoughts I've had:
  1. Could this take us a lot closer to a user-centric identity?  Imagine if this software was built into the phone (so you didn't have to run an App to make it work).  
  2. Something like this would be interesting from a multi-auth perspective.  On the one hand, it could preclude the need for mulit-auth because a person could turn off his OP when the app isn't running (thus ensuring no RP logins without the phone....mostly -- see some security drawbacks below).  
  3. Alternatively, it could provide one multi-auth solution in that an RP could be required to get an assertion from a "regular" OP and a user-centric OP (like the iPhone) before allowing access.
Security Drawbacks (?)
  1. The user should trust his/her DDNS provider because somebody at that provider could change the IP address hooked up to the domain backing the iPhoneOP (without the knowledge of the user).  However, this is an issue with current OPs (the rogue employee problem).  Either could be mitigated with multi-auth.
_______________________________________________ general mailing list general <at> lists.openid.net http://lists.openid.net/mailman/listinfo/openid-general No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.733 / Virus Database: 271.1.1/2720 - Release Date: 03/03/10 02:34:00 
_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Permalink | Reply |
headers
David Fuelling | 3 Mar 2010 21:58
Picon
Gravatar

Re: [OpenID] UCI Idea: An iPhone OP (?)

That's incredible, and very cool!!  


I don't know that much about SAML, but it seems like a SAML IdP can use an individual user's key-pair to create an assertion that an RP can use to allow a login (a "signed assertion")?

From TFA: "Then the IdP on the mobile phone creates an SAML assertion and signs the assertion with the private key of the mobile phone".

OpenID doesn't have the ability to sign assertions like this, does it?  


On Wed, Mar 3, 2010 at 12:03 PM, Paul Madsen <paulmadsen <at> rogers.com> wrote:
Hi David, NTT built something like you describe for SAML SSO - specifically the scenario you list below in #4

http://www.projectliberty.org/liberty/content/download/3960/26523/file/NTT-SASSO%20liberty%20case%20study.pdf

paul


_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Permalink | Reply |
headers
Paul Madsen | 4 Mar 2010 00:05
Favicon

Re: [OpenID] UCI Idea: An iPhone OP (?)

Thanks David,

SAML allows that the IDP sign assertions and/or messages.

In this case, the IdP on the phone just uses the RSA keys it has on hand to do the signing - which are those on the user's SIM. (there are of course correlation/privacy implications of signing assertions with user keys)

There are times where its useful to be able to sign a SAML assertion separate from the message that carries it (if you want to be able to subsequently use it) - but I dont think this is one of them.

So, I dont see why the fact that OpenID doesnt have something comparable to 'assertions' would prevent the 'OP on phone' model you're thinking of

paul

On 3/3/2010 3:58 PM, David Fuelling wrote:
That's incredible, and very cool!!  

I don't know that much about SAML, but it seems like a SAML IdP can use an individual user's key-pair to create an assertion that an RP can use to allow a login (a "signed assertion")?

From TFA: "Then the IdP on the mobile phone creates an SAML assertion and signs the assertion with the private key of the mobile phone".

OpenID doesn't have the ability to sign assertions like this, does it?  


On Wed, Mar 3, 2010 at 12:03 PM, Paul Madsen <paulmadsen <at> rogers.com> wrote:
Hi David, NTT built something like you describe for SAML SSO - specifically the scenario you list below in #4

http://www.projectliberty.org/liberty/content/download/3960/26523/file/NTT-SASSO%20liberty%20case%20study.pdf

paul


No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.733 / Virus Database: 271.1.1/2720 - Release Date: 03/03/10 02:34:00 
_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Permalink | Reply |
headers
Paul Madsen | 3 Mar 2010 18:03
Favicon

Re: [OpenID] UCI Idea: An iPhone OP (?)

Hi David, FYI, NTT built something like you describe for SAML SSO - specifically the scenario you list below in #4

http://www.projectliberty.org/liberty/content/download/3960/26523/file/NTT-SASSO%20liberty%20case%20study.pdf

paul

On 3/3/2010 11:33 AM, David Fuelling wrote:
Wondering what people think about using as an iPhone (or Android/etc) application as a personal OP.  

Basically, the way it would work is as follows:
  1. Go to RP, get prompted with a login form.
  2. Turn on iPhoneOP application on your iPhone.
    1. iPhone App turns on lighttpd (or some other ultra-small web server) to serve web requests from the phone and act as an OP.
    2. iPhone App then connects to a DDNS service that connects the phone's current IPV6 address to the OP domain.
    3. The iPhone is now the user's OP.
  3. User signs into the RP, which then does the OpenID dance with the OP running on the user's iphone.
  4. The user could login via the web, or optionally just get prompted on the phone that a login is occurring - the user could then accept the login and/or enter a security code (in case of a lost iPhone).
  5. User is logged-into the RP.
  6. iPhone App turns off.
Some initial thoughts I've had:
  1. Could this take us a lot closer to a user-centric identity?  Imagine if this software was built into the phone (so you didn't have to run an App to make it work).  
  2. Something like this would be interesting from a multi-auth perspective.  On the one hand, it could preclude the need for mulit-auth because a person could turn off his OP when the app isn't running (thus ensuring no RP logins without the phone....mostly -- see some security drawbacks below).  
  3. Alternatively, it could provide one multi-auth solution in that an RP could be required to get an assertion from a "regular" OP and a user-centric OP (like the iPhone) before allowing access.
Security Drawbacks (?)
  1. The user should trust his/her DDNS provider because somebody at that provider could change the IP address hooked up to the domain backing the iPhoneOP (without the knowledge of the user).  However, this is an issue with current OPs (the rogue employee problem).  Either could be mitigated with multi-auth.
_______________________________________________ general mailing list general <at> lists.openid.net http://lists.openid.net/mailman/listinfo/openid-general No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.733 / Virus Database: 271.1.1/2720 - Release Date: 03/03/10 02:34:00 
_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Permalink | Reply |

Gmane