RE: Special Request: Client Certificates vs. OpenID
My question was a little different than your response. I understand that Client Certificates can be used in addition to, but I was asking about documenting scenarios in blog entries where it could be used instead of. For example, if the Pharma SAFE (http://www.cybertrust.com/pr_events/press_releases/2005/03/29/) where to look at their problem space in 2007, would they have chosen client certificates. -Original Message- From: Alaric Dailey [mailto:[EMAIL PROTECTED] Sent: Monday, January 22, 2007 2:02 PM To: McGovern, James F (HTSC, IT); specs@openid.net Subject: RE: Special Request: Client Certificates vs. OpenID Client certificates could easily be used to extend openID, and since (last time I checked) the authentication process was entirely up to the IdP, a client certificate based IdP should be open to be created. Most CAs have created a problem because they only allow a user to use their certs (mostly because CAs don't all follow the same persona verification standards, and to a lesser degree politics). Now, over at StartCom, Eddy has created a system where users are allowed to register any certificate they like to login, very much like the USPS has done for the "Electronic Post Mark". * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
OpenID and phishing (was Announcing OpenID Authentication 2.0 - Implementor's Draft 11)
On 19 Jan 2007, at 14:19, Ben Laurie wrote: > Still totally unhappy about the phishing issues, which I blogged > about here: > > http://www.links.org/?p=187 I have a proposal which I think could greatly reduce the risk of phishing: identity providers should /never/ display their login form (or a link to the form) on a page that has been redirected to by an OpenID consumer. Instead, they should instruct the user to navigate to the login page themselves. The login page should have a short, memorable URL and users should be encouraged to bookmark it themselves when they sign up for the provider. The OpenID "landing page" then becomes an opportunity to help protect users against phishing rather than just being a vector for the attack. I've fleshed this out on my blog: http://simonwillison.net/2007/Jan/19/phishing/ Does that sound workable? Cheers, Simon ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [OpenID] OpenID and phishing (was Announcing OpenID Authentication2.0 - Implementor's Draft 11)
On 19 Jan 2007, at 15:06, Scott Kveton wrote: > What if the OP cataloged where you just came from and then > presented the > screen that you mention? The user is asked to navigate via a > bookmark or > entering the URL in the location bar and then upon logging in is > presented > with a link back to the site they just came from. Then the user > can quickly > engage and the site can still kick of the SREG mojo instead of > having to go > _back_ to the site in question to re-initiate the login. That's actually what I had in mind - I should have made that more clear. When you arrive on the landing page a cookie is set to allow the site to track your half-complete authentication request; once you log in you get a link to continue with that authentication. I totally agree that the best thing about OpenID is that it lowers the barrier to engagement. My hope is that most users will be logged in to their OP most of the time, so they will actually very rarely see the landing page. Cheers, Simon ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [security] [OpenID] Announcing OpenID Authentication 2.0 - Implementor's Draft 11
2007/1/22, Ben Laurie <[EMAIL PROTECTED]>: > Actually, it appears to allow the RP to tell the OP what kind of > authentication was used, which is backwards. > > It also seems to be rather lacking in meat. Still, a step in the right > direction. > I asked this question some time ago: is there any possibility for RP to ask OP to use some authentication method? Or another scenario: how can user select one of OP's for this particular authentication from his Yadis file. regards, Marcin ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [OpenID] Announcing OpenID Authentication 2.0 - Implementor'sDraft 11
On Mon, 22 Jan 2007, Hallam-Baker, Phillip wrote: > On the contrary, PKI is the basis of the security infrastructure > that so far has provided the greatest defense against Internet crime - SSL. > > Judged by any rational set of standards SSL has been the most > successful security protocol of all time. The costs of the PKI > infrastructure are negligible compared to the value of the commerce > it supports. In practice SSL is primarily used to establish an encrypted channel between endpoints, not to establish reliable reciprocal identification. Given that almost no users pay any attention to certificates, what reason do we have to believe that SSL succeeds because of PKI, rather than in spite of it? By what rational set of standards do you evaluate PKI -- how frequently it is used, or how much fraud it actually prevents? -- ?!ng ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Announcing OpenID Authentication 2.0 - Implementor'sDraft 11
On Mon, Jan 22, 2007 at 04:53:11PM +, Ben Laurie <[EMAIL PROTECTED]> wrote a message of 21 lines which said: > Why not? The man in the middle sees what you would see, surely? OK, sorry, I replied too fast. I was replying in the context of a phishing attempt by a rogue RP redirecting to a pirate OP posing as the legitimate OP. If sessions are not protected by TLS, indeed, a real MitM (able to observe and to modify) can subvert the "shared secret" method. However, it makes the attack much more difficult, no? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [OpenID] Announcing OpenID Authentication 2.0 - Implementor'sDraft 11
SSL achieves the original security goals set for it. SSL does not achieve every security goal, that is not a failure. Certainly there are no grounds for the claim PKI has failed when it has succeeded in its original limited goals. I agree that the original goals were too narrow. That is an argument I made ten years ago. This is partly about correcting that original mistake. > -Original Message- > From: Ka-Ping Yee [mailto:[EMAIL PROTECTED] > Sent: Monday, January 22, 2007 3:05 PM > To: Hallam-Baker, Phillip > Cc: James A. Donald; Ben Laurie; specs@openid.net; > openid-general; heraldry-dev@incubator.apache.org > Subject: Re: [OpenID] Announcing OpenID Authentication 2.0 - > Implementor'sDraft 11 > > On Mon, 22 Jan 2007, Hallam-Baker, Phillip wrote: > > On the contrary, PKI is the basis of the security > infrastructure that > > so far has provided the greatest defense against Internet > crime - SSL. > > > > Judged by any rational set of standards SSL has been the most > > successful security protocol of all time. The costs of the PKI > > infrastructure are negligible compared to the value of the > commerce it > > supports. > > In practice SSL is primarily used to establish an encrypted > channel between endpoints, not to establish reliable > reciprocal identification. > Given that almost no users pay any attention to certificates, > what reason do we have to believe that SSL succeeds because > of PKI, rather than in spite of it? > > By what rational set of standards do you evaluate PKI -- how > frequently it is used, or how much fraud it actually prevents? > > > -- ?!ng > ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Special Request: Client Certificates vs. OpenID
So I've been doing some asking around who might be interested in co- authoring some kind of white paper on the subject of user-centric identity in/for the enterprise. There are some volunteers with a variety of view points -- no guarantees that we'll manage to produce something collaboratively (cross-vendor white papers tend to be hard) -- and we'll see where that goes. That only goes partially to your point, but it is a step. On Jan 22, 2007, at 9:08, McGovern, James F ((HTSC, IT)) wrote: Last week I sent a note to the list inquiring whether anyone on this list wanted to participate in our industry vertical standards body in hopes of ratifying OpenID as an endorsed horizontal specification. In terms of preparation, it would be greatly appreciated if Dick Hardt, Johannes Ernst and other bloggers could from their blog discuss user-centric identity as a potential solution to industry vertical concerns since nothing neutral (produced by a vendor and not an insurance carrier) exists in this regard. Other industry verticals such as Pharmaceutical have embraced PKI approaches where they issue client certificates to participants. Many PKI vendors have in secret created user certificate management issues, the inability to allow for roaming users, sharing of desktops, and other concerns that I am of the belief that user- centric approaches could handle. Of course PKI-centric and user- centric don't have to be mutually exclusive but it would be wonderful if the blog entry reflected how approaches such as SAFE (pharma) would have looked in a user-centric world. ** *** This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. ** *** ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
OpenID Auth 2.0 security considerations
What about a non-normative link from the spec to a place on the wiki where we can collect security considerations for it, and update those in real-time as discussions such as the phishing one progress. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [OpenID] Announcing OpenID Authentication 2.0 - Implementor'sDraft 11
On the contrary, PKI is the basis of the security infrastructure that so far has provided the greatest defense against Internet crime - SSL. Judged by any rational set of standards SSL has been the most successful security protocol of all time. The costs of the PKI infrastructure are negligible compared to the value of the commerce it supports. There are uses of S/MIME that do provide effective security controls for the community that applies them. But any CA that continues to advocate per-user certs in place of domain level authentication has failled to understand their real business interests. > -Original Message- > From: James A. Donald [mailto:[EMAIL PROTECTED] > Sent: Monday, January 22, 2007 1:42 PM > To: Ben Laurie > Cc: Hallam-Baker, Phillip; specs@openid.net; openid-general; > heraldry-dev@incubator.apache.org > Subject: Re: [OpenID] Announcing OpenID Authentication 2.0 - > Implementor'sDraft 11 > > Hallam-Baker, Phillip > > > > If you change the browser you might as well really > > > > change the browser and use a strong authentication > > > > mechanism based on PKI > > Ben Laurie > > > I'm sure you meant to say "based on asymmetric > > > cryptography". > > Hallam-Baker, Phillip > > No, any time you have a trusted key you have an > infrastructure. > > No you do not, nor is PKI useful in solving phishing. > > PKI is a solution that has been tried and has failed. > It has become an obstacle, as commercial interests actively > block alternatives that do not involve a small number of > centralized authorities with a special privilege that enables > them to intrude between client and server and charge the server. > > ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [OpenID] CROSS POSTING :-(
I'd have to agree. I realize I am guilty for the start of this thread announcing the new spec draft, though am hoping we can move this discussion to [EMAIL PROTECTED] if that works for people. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gabe Wachob Sent: Monday, January 22, 2007 11:05 AM To: heraldry-dev@incubator.apache.org; [EMAIL PROTECTED]; specs@openid.net; 'openid-general' Subject: [OpenID] CROSS POSTING :-( This is getting a little insane - many of us are subscribed to the four lists that this thread has been posted to. One person has suggested that we actually consolidate the separate lists given the overlap in membership and topics (at least the openid lists). The other option is to be more disciplined about posting. In any case, having most threads cross posted to 4 lists seems insane and unworkable to me. What's the mood on consolidating the lists? I'd rather we just be careful about cross posting and keep the separate lists, but that may be too much to ask. -Gabe P.S. Yes, I realize this is cross posted ;-) > -Original Message- > From: Marcin Jagodziński [mailto:[EMAIL PROTECTED] > Sent: Monday, January 22, 2007 10:47 AM > To: Ben Laurie > Cc: Josh Hoyt; [EMAIL PROTECTED]; specs@openid.net; openid-general; > heraldry-dev@incubator.apache.org > Subject: Re: [security] [OpenID] Announcing OpenID Authentication 2.0 > - Implementor's Draft 11 > > 2007/1/22, Ben Laurie <[EMAIL PROTECTED]>: > > Actually, it appears to allow the RP to tell the OP what kind of > > authentication was used, which is backwards. > > > > It also seems to be rather lacking in meat. Still, a step in the > > right direction. > > > > I asked this question some time ago: is there any possibility for RP > to ask OP to use some authentication method? Or another scenario: how > can user select one of OP's for this particular authentication from > his Yadis file. > > regards, > > Marcin ___ general mailing list [EMAIL PROTECTED] http://openid.net/mailman/listinfo/general ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
CROSS POSTING :-(
This is getting a little insane - many of us are subscribed to the four lists that this thread has been posted to. One person has suggested that we actually consolidate the separate lists given the overlap in membership and topics (at least the openid lists). The other option is to be more disciplined about posting. In any case, having most threads cross posted to 4 lists seems insane and unworkable to me. What's the mood on consolidating the lists? I'd rather we just be careful about cross posting and keep the separate lists, but that may be too much to ask. -Gabe P.S. Yes, I realize this is cross posted ;-) > -Original Message- > From: Marcin Jagodziński [mailto:[EMAIL PROTECTED] > Sent: Monday, January 22, 2007 10:47 AM > To: Ben Laurie > Cc: Josh Hoyt; [EMAIL PROTECTED]; specs@openid.net; openid-general; > heraldry-dev@incubator.apache.org > Subject: Re: [security] [OpenID] Announcing OpenID Authentication 2.0 - > Implementor's Draft 11 > > 2007/1/22, Ben Laurie <[EMAIL PROTECTED]>: > > Actually, it appears to allow the RP to tell the OP what kind of > > authentication was used, which is backwards. > > > > It also seems to be rather lacking in meat. Still, a step in the right > > direction. > > > > I asked this question some time ago: is there any possibility for RP > to ask OP to use some authentication method? Or another scenario: how > can user select one of OP's for this particular authentication from > his Yadis file. > > regards, > > Marcin ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Special Request: Client Certificates vs. OpenID
Client certificates could easily be used to extend openID, and since (last time I checked) the authentication process was entirely up to the IdP, a client certificate based IdP should be open to be created. Most CAs have created a problem because they only allow a user to use their certs (mostly because CAs don't all follow the same persona verification standards, and to a lesser degree politics). Now, over at StartCom, Eddy has created a system where users are allowed to register any certificate they like to login, very much like the USPS has done for the "Electronic Post Mark". > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of McGovern, > James F (HTSC, IT) > Sent: Monday, January 22, 2007 11:08 AM > To: specs@openid.net > Subject: Special Request: Client Certificates vs. OpenID > > Last week I sent a note to the list inquiring whether anyone > on this list wanted to participate in our industry vertical > standards body in hopes of ratifying OpenID as an endorsed > horizontal specification. In terms of preparation, it would > be greatly appreciated if Dick Hardt, Johannes Ernst and > other bloggers could from their blog discuss user-centric > identity as a potential solution to industry vertical > concerns since nothing neutral (produced by a vendor and not > an insurance carrier) exists in this regard. > > Other industry verticals such as Pharmaceutical have embraced > PKI approaches where they issue client certificates to > participants. Many PKI vendors have in secret created user > certificate management issues, the inability to allow for > roaming users, sharing of desktops, and other concerns that I > am of the belief that user-centric approaches could handle. > Of course PKI-centric and user-centric don't have to be > mutually exclusive but it would be wonderful if the blog > entry reflected how approaches such as SAFE (pharma) would > have looked in a user-centric world. > ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [OpenID] Announcing OpenID Authentication 2.0 - Implementor's Draft 11
On 1/22/07, Ben Laurie <[EMAIL PROTECTED]> wrote: > On 1/22/07, Josh Hoyt <[EMAIL PROTECTED]> wrote: > > On 1/22/07, Ben Laurie <[EMAIL PROTECTED]> wrote: > > > > On 1/22/07, Ben Laurie <[EMAIL PROTECTED]> wrote: > > > > > OK, the idea is pretty simple. Rather like the "OpenID Authentication > > > > > Security Profiles" you have a profile where the RP states what kind of > > > > > End User/OP authentication is acceptable to it. Sites with low/zero > > > > > value attached to the login can accept any kind of EU/OP auth, whereas > > > > > high value sites can require "unphishable" auth. > > > > > > > > I like the sound of this proposal, but I don't see how the RP could > > > > know whether the OP is actually using "unphishable" authentication > > > > when that kind of authentication is requested. Is it necessary for the > > > > RP to be able to tell for sure, and if so, how could it tell? > > > > > > No, I don't think it is necessary. If users want to trust their > > > identity to OPs that lie, that's their decision. > > > > In that case, I think this could just be part of the "Assertion > > Quality Extension." [1] I haven't been involved in that specification > > at all, but my understanding is that it provides a way of expressing > > what kind of authentication the RP would like to have when a request > > is made to the OP. > > Actually, it appears to allow the RP to tell the OP what kind of > authentication was used, which is backwards. Sorry, I mean the OP to tell the RP! > > It also seems to be rather lacking in meat. Still, a step in the right > direction. > > > > > Josh > > > > 1. http://openid.net/specs/openid-assertion-quality-extension-1_0-01.html > > > ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [OpenID] Announcing OpenID Authentication 2.0 - Implementor'sDraft 11
Hallam-Baker, Phillip > > > If you change the browser you might as well really > > > change the browser and use a strong authentication > > > mechanism based on PKI Ben Laurie > > I'm sure you meant to say "based on asymmetric > > cryptography". Hallam-Baker, Phillip > No, any time you have a trusted key you have an > infrastructure. No you do not, nor is PKI useful in solving phishing. PKI is a solution that has been tried and has failed. It has become an obstacle, as commercial interests actively block alternatives that do not involve a small number of centralized authorities with a special privilege that enables them to intrude between client and server and charge the server. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: 2.0 Spec Questions
On 21-Jan-07, at 4:48 PM, James McGovern wrote: > Several questions after reading the 2.0 spec - draft 11. > > 1. The definition of realm if I am reading it correctly could be > problematic > in large enterprises. For example, if one were using a web access > management > product, they would have the ability to define a realm in terms of > a listing > of discrete hosts that may or may not fit a URL pattern matching > approach. > For example, I could have a demographic called consumers who could > access > hosts such as http://myconsumer.example.com , > http://printstatements.example.com, http://paybills.example.com > Likewise > another demographic called Business Partner may have a different > set of > hosts they can interact with. The motivation of the realm is to deal with web sites where there are many host names, but really one site -- LiveJournal being the motivating use case, as well as being where OpenID got its start. Each blog has a separate hostname: dick.livejournal.com brad.livejournal.com Since different blogs have different hostnames, but a user thinks of them all as being lLiveJournal, so being able to have a realm of: *.livejournal.com > > 2. In terms of checking the nonce, can we recommend that a deployment > practice should be to use the NTP protocol and point to clocks of a > certain > stratum? Likewise, would it be a good idea if an association could > indicate > how much skew it would accept before rejecting? The date-time stamp in the nonce is really to assist the RP in knowing that it can discard a message if it is older then a x period rather then having to hold every nonce received. I don't know how much skew happens out in the wild these days, but perhaps we could get an idea of what that is and then recommend how long the RP should keep a nonce before discarding? > > 3. In terms of an extension, should an OP be able to indicate when > reauth > may be required so the user doesn't assume that if they > authenticate once > they are always good? AuthN is for the benefit of the RP. While one view might be that the OP should be able to dictate how long the AuthN is good for, once used, it is really the RP that is determining if it is the same user. I think the more important consideration is the RP wanting to get the OP to do AuthN for the user instead of using a cached AuthN. I wanted to put it in the spec, but the decision was that it was better in an extension. > > 4. Some portions of the spec are heavily coupled to PKI. How should > growing > users of IBE think of this? Besides recommending sites use TLS, I don't see the PKI coupling you are referring to. Would you elaborate? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [OpenID] Announcing OpenID Authentication 2.0 - Implementor's Draft 11
On 1/22/07, Josh Hoyt <[EMAIL PROTECTED]> wrote: > On 1/22/07, Ben Laurie <[EMAIL PROTECTED]> wrote: > > > On 1/22/07, Ben Laurie <[EMAIL PROTECTED]> wrote: > > > > OK, the idea is pretty simple. Rather like the "OpenID Authentication > > > > Security Profiles" you have a profile where the RP states what kind of > > > > End User/OP authentication is acceptable to it. Sites with low/zero > > > > value attached to the login can accept any kind of EU/OP auth, whereas > > > > high value sites can require "unphishable" auth. > > > > > > I like the sound of this proposal, but I don't see how the RP could > > > know whether the OP is actually using "unphishable" authentication > > > when that kind of authentication is requested. Is it necessary for the > > > RP to be able to tell for sure, and if so, how could it tell? > > > > No, I don't think it is necessary. If users want to trust their > > identity to OPs that lie, that's their decision. > > In that case, I think this could just be part of the "Assertion > Quality Extension." [1] I haven't been involved in that specification > at all, but my understanding is that it provides a way of expressing > what kind of authentication the RP would like to have when a request > is made to the OP. Actually, it appears to allow the RP to tell the OP what kind of authentication was used, which is backwards. It also seems to be rather lacking in meat. Still, a step in the right direction. > > Josh > > 1. http://openid.net/specs/openid-assertion-quality-extension-1_0-01.html > ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [OpenID] Announcing OpenID Authentication 2.0 - Implementor's Draft 11
On 1/22/07, Ben Laurie <[EMAIL PROTECTED]> wrote: > > On 1/22/07, Ben Laurie <[EMAIL PROTECTED]> wrote: > > > OK, the idea is pretty simple. Rather like the "OpenID Authentication > > > Security Profiles" you have a profile where the RP states what kind of > > > End User/OP authentication is acceptable to it. Sites with low/zero > > > value attached to the login can accept any kind of EU/OP auth, whereas > > > high value sites can require "unphishable" auth. > > > > I like the sound of this proposal, but I don't see how the RP could > > know whether the OP is actually using "unphishable" authentication > > when that kind of authentication is requested. Is it necessary for the > > RP to be able to tell for sure, and if so, how could it tell? > > No, I don't think it is necessary. If users want to trust their > identity to OPs that lie, that's their decision. In that case, I think this could just be part of the "Assertion Quality Extension." [1] I haven't been involved in that specification at all, but my understanding is that it provides a way of expressing what kind of authentication the RP would like to have when a request is made to the OP. Josh 1. http://openid.net/specs/openid-assertion-quality-extension-1_0-01.html ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [OpenID] Announcing OpenID Authentication 2.0 - Implementor'sDraft 11
On 1/22/07, Hallam-Baker, Phillip <[EMAIL PROTECTED]> wrote: > > > From: Ben Laurie [mailto:[EMAIL PROTECTED] > > > > The only way that I can see that you are going to > > circumvent an attempt using existing browser capabilities is > > to introduce a malicious login page is through use of some > > form of shared secret such as a picture of a cuddly animal > > chosen by the user or Secure Letterhead. > > > > How is this kind of shared secret a defence against a MitM? > > Good question to address to those vendors selling such schemes. > > There are controls that can be put in place to control attempts to capture > the shared secret but these rely on a lot of active defense infrastructure > that it is dangerous to assume could be deployed by low end IdPs. The bigger > problem is getting users to insist on the display of their secret before > entering their details. Witness the recent rash of phishing attacks against > these schemes. > > > > > Letterhead requires a browser upgrade so it breaks the > > 'existing capabilities' constraint. > > > > > > If you change the browser you might as well really change > > the browser > > > and use a strong authentication mechanism based on PKI > > > > I'm sure you meant to say "based on asymmetric cryptography". > > No, any time you have a trusted key you have an infrastructure. Well, if you count "give a copy of the public key to the OP" as infrastructure, then sure. > Some infrastructures have much higher costs than others. Support for offline > verification as the Kohnfelder architecture attempts is very expensive. Key > centric architectures are much lighter weight. > > The reason I state PKI is not to say 'it must be X.509', its because PKIX got > the way it did largely because people underspecified and underarchitected in > the beginning and then a bunch of folk resisted necessary features rather > than working out early on how to accommodate them. The result being a series > of extensions on extensions and no overall coherence. > > ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [OpenID] Announcing OpenID Authentication 2.0 - Implementor's Draft 11
On 1/22/07, Josh Hoyt <[EMAIL PROTECTED]> wrote: > Ben, > > On 1/22/07, Ben Laurie <[EMAIL PROTECTED]> wrote: > > OK, the idea is pretty simple. Rather like the "OpenID Authentication > > Security Profiles" you have a profile where the RP states what kind of > > End User/OP authentication is acceptable to it. Sites with low/zero > > value attached to the login can accept any kind of EU/OP auth, whereas > > high value sites can require "unphishable" auth. > > I like the sound of this proposal, but I don't see how the RP could > know whether the OP is actually using "unphishable" authentication > when that kind of authentication is requested. Is it necessary for the > RP to be able to tell for sure, and if so, how could it tell? No, I don't think it is necessary. If users want to trust their identity to OPs that lie, that's their decision. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [OpenID] Announcing OpenID Authentication 2.0 - Implementor's Draft 11
Ben, On 1/22/07, Ben Laurie <[EMAIL PROTECTED]> wrote: > OK, the idea is pretty simple. Rather like the "OpenID Authentication > Security Profiles" you have a profile where the RP states what kind of > End User/OP authentication is acceptable to it. Sites with low/zero > value attached to the login can accept any kind of EU/OP auth, whereas > high value sites can require "unphishable" auth. I like the sound of this proposal, but I don't see how the RP could know whether the OP is actually using "unphishable" authentication when that kind of authentication is requested. Is it necessary for the RP to be able to tell for sure, and if so, how could it tell? Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [OpenID] Announcing OpenID Authentication 2.0 - Implementor'sDraft 11
> From: Ben Laurie [mailto:[EMAIL PROTECTED] > > The only way that I can see that you are going to > circumvent an attempt using existing browser capabilities is > to introduce a malicious login page is through use of some > form of shared secret such as a picture of a cuddly animal > chosen by the user or Secure Letterhead. > > How is this kind of shared secret a defence against a MitM? Good question to address to those vendors selling such schemes. There are controls that can be put in place to control attempts to capture the shared secret but these rely on a lot of active defense infrastructure that it is dangerous to assume could be deployed by low end IdPs. The bigger problem is getting users to insist on the display of their secret before entering their details. Witness the recent rash of phishing attacks against these schemes. > > Letterhead requires a browser upgrade so it breaks the > 'existing capabilities' constraint. > > > > If you change the browser you might as well really change > the browser > > and use a strong authentication mechanism based on PKI > > I'm sure you meant to say "based on asymmetric cryptography". No, any time you have a trusted key you have an infrastructure. Some infrastructures have much higher costs than others. Support for offline verification as the Kohnfelder architecture attempts is very expensive. Key centric architectures are much lighter weight. The reason I state PKI is not to say 'it must be X.509', its because PKIX got the way it did largely because people underspecified and underarchitected in the beginning and then a bunch of folk resisted necessary features rather than working out early on how to accommodate them. The result being a series of extensions on extensions and no overall coherence. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Special Request: Client Certificates vs. OpenID
Last week I sent a note to the list inquiring whether anyone on this list wanted to participate in our industry vertical standards body in hopes of ratifying OpenID as an endorsed horizontal specification. In terms of preparation, it would be greatly appreciated if Dick Hardt, Johannes Ernst and other bloggers could from their blog discuss user-centric identity as a potential solution to industry vertical concerns since nothing neutral (produced by a vendor and not an insurance carrier) exists in this regard. Other industry verticals such as Pharmaceutical have embraced PKI approaches where they issue client certificates to participants. Many PKI vendors have in secret created user certificate management issues, the inability to allow for roaming users, sharing of desktops, and other concerns that I am of the belief that user-centric approaches could handle. Of course PKI-centric and user-centric don't have to be mutually exclusive but it would be wonderful if the blog entry reflected how approaches such as SAFE (pharma) would have looked in a user-centric world. * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Announcing OpenID Authentication 2.0 - Implementor'sDraft 11
On 1/22/07, Stephane Bortzmeyer <[EMAIL PROTECTED]> wrote: > On Mon, Jan 22, 2007 at 03:36:44PM +, > Ben Laurie <[EMAIL PROTECTED]> wrote > a message of 28 lines which said: > > > > The only way that I can see that you are going to circumvent an > > > attempt using existing browser capabilities is to introduce a > > > malicious login page is through use of some form of shared secret > > > such as a picture of a cuddly animal chosen by the user or Secure > > > Letterhead. > > > How is this kind of shared secret a defence against a MitM? > > If you see the cuddly animal as the background image of the login > screen, you know you see the authentic login form. If you see an ugly > beast, it means there is a Man in the Middle. > > The MitM cannot fake the login screen because he does not know the > animal you choosed (the shared secret). Why not? The man in the middle sees what you would see, surely? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Announcing OpenID Authentication 2.0 - Implementor'sDraft 11
On Mon, Jan 22, 2007 at 03:36:44PM +, Ben Laurie <[EMAIL PROTECTED]> wrote a message of 28 lines which said: > > The only way that I can see that you are going to circumvent an > > attempt using existing browser capabilities is to introduce a > > malicious login page is through use of some form of shared secret > > such as a picture of a cuddly animal chosen by the user or Secure > > Letterhead. > How is this kind of shared secret a defence against a MitM? If you see the cuddly animal as the background image of the login screen, you know you see the authentic login form. If you see an ugly beast, it means there is a Man in the Middle. The MitM cannot fake the login screen because he does not know the animal you choosed (the shared secret). ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [OpenID] Announcing OpenID Authentication 2.0 - Implementor'sDraft 11
On 1/22/07, Hallam-Baker, Phillip <[EMAIL PROTECTED]> wrote: > > > [mailto:[EMAIL PROTECTED] On Behalf Of Ben Laurie > > > More importantly, I think I have a solution that will make > > both of us happy, but I now have to go and ride my motorbike > > fast, so I'll detail it later. > > Now there is an exit line to tempt the Gods. > > > The only way that I can see that you are going to circumvent an attempt using > existing browser capabilities is to introduce a malicious login page is > through use of some form of shared secret such as a picture of a cuddly > animal chosen by the user or Secure Letterhead. How is this kind of shared secret a defence against a MitM? > Letterhead requires a browser upgrade so it breaks the 'existing > capabilities' constraint. > > If you change the browser you might as well really change the browser and use > a strong authentication mechanism based on PKI I'm sure you meant to say "based on asymmetric cryptography". > I think we need to take another look at the 'change the browser' case and > make sure that we can take full advantage if the browser is changed. Damn straight. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [OpenID] Announcing OpenID Authentication 2.0 - Implementor'sDraft 11
> [mailto:[EMAIL PROTECTED] On Behalf Of Ben Laurie > More importantly, I think I have a solution that will make > both of us happy, but I now have to go and ride my motorbike > fast, so I'll detail it later. Now there is an exit line to tempt the Gods. The only way that I can see that you are going to circumvent an attempt using existing browser capabilities is to introduce a malicious login page is through use of some form of shared secret such as a picture of a cuddly animal chosen by the user or Secure Letterhead. Letterhead requires a browser upgrade so it breaks the 'existing capabilities' constraint. If you change the browser you might as well really change the browser and use a strong authentication mechanism based on PKI I think we need to take another look at the 'change the browser' case and make sure that we can take full advantage if the browser is changed. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [OpenID] Announcing OpenID Authentication 2.0 - Implementor's Draft 11
On 1/21/07, Ben Laurie <[EMAIL PROTECTED]> wrote: > On 1/19/07, Dick Hardt <[EMAIL PROTECTED]> wrote: > > > > On 19-Jan-07, at 6:19 AM, Ben Laurie wrote: > > > > > > > > Still totally unhappy about the phishing issues, which I blogged > > > about here: > > > > > > http://www.links.org/?p=187 > > > > There are numerous ways of solving this. Several standard methods can > > solve it. It is a relationship between the user and the OP and the RP > > is not party, so I don't think it belongs in the OpenID > > Authentication specification. > > > > That does not mean it is not important, just that *this* spec is not > > the right place. > > I think that's entirely wrong. The RP doesn't care at all about the OP > - all the RP cares about is the end user. > > More importantly, I think I have a solution that will make both of us > happy, but I now have to go and ride my motorbike fast, so I'll detail > it later. OK, the idea is pretty simple. Rather like the "OpenID Authentication Security Profiles" you have a profile where the RP states what kind of End User/OP authentication is acceptable to it. Sites with low/zero value attached to the login can accept any kind of EU/OP auth, whereas high value sites can require "unphishable" auth. Obviously some serious work is needed to flesh out this proposal, but it seems to me it allows OpenID to stay lightweight (and phishable) where appropriate, but also to serve a useful purpose for high-value applications. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
