[Security] client-to-client security :: Summary and todo's

Pavel Simerda pavlix at pavlix.net
Sat Aug 23 15:08:52 CDT 2008


On Sat, 23 Aug 2008 20:12:36 +0300
Hannes Tschofenig <Hannes.Tschofenig at gmx.net> wrote:

> Pavel, Dirk,
> 
> Pavel Simerda wrote:
> > On Sat, 23 Aug 2008 18:21:38 +0200
> > Dirk Meyer <dmeyer at tzi.de> wrote:
> >
> >   
> >> Pavel Simerda wrote:
> >>     
> >>> On Sat, 23 Aug 2008 16:23:28 +0200
> >>> Dirk Meyer <dmeyer at tzi.de> wrote:
> >>>
> >>>       
> >>>> Pedro Melo wrote:
> >>>>         
> >>>>> Hi,
> >>>>>
> >>>>> On Aug 23, 2008, at 2:12 PM, Dirk Meyer wrote:
> >>>>>           
> >>>>>> IMHO OAuth is kind of stupid. I have to trust a server I do not
> >>>>>> know. No, the point is that I can upload a certificate to my
> >>>>>> XMPP server and the owner of that certificate (a bot, a client
> >>>>>> I do not trust) can log in using SASL-EXTERNAL as me without
> >>>>>> having the password.
> >>>>>>             
> >>>>> OAuth is not stupid. The server you do not trust is your own
> >>>>> XMPP server. If you don't trust that, well, what are you doing
> >>>>> connected to him?
> >>>>>           
> >>>> Oops, sorry, I messed up OAuth and OpenID. My fault, ignore me.
> >>>>
> >>>>         
> >>> Neither OpenID seems stupid to me. "Stupid" is a word that only
> >>> means you didn't bother to find more information. When one knows
> >>> what's going on, he might use "insuitable for oure purpose
> >>> because...".
> >>>       
> >> OK, "stupid" is a bad word. Maybe: good good idea lost. The
> >> propblem is that OpenID provider do not trust each other (except
> >> for blogs maybe). E.g. every Yahoo id is an OpenID ... great. But
> >> I need a Yahoo id to log on into flickr because they do not trust
> >> my OpenID server. We also plan to install OpenID here at the
> >> university for some stuff but you must have an OpenID from the
> >> university because we do not trust Yahoo. So instead to have one
> >> OpenID (good idea) you have several (good idea lost). But that is
> >> my opinion. 
> >
> > 1) I only use one and that is "pavlix.net"
> >
> > It is delegated to http://xmppid.net/pavlix[AT]pavlix.net ([AT] =
> > @), that is verified through Jabber and that's it.
> >
> > 2) If a service requires a particular OpenID provieder for
> > authentication, it's their problem, it doesn't fit the main OpenID
> > use cases.
> >
> > This is not a drawback of OpenID but it is a use of OpenID for
> > private purposes.
> >
> > This would be like saying that Jabber is bad because we don't trust
> > jabberfr.org and we won't talk to them unless they are given JIDs
> > from xyz.com.
> >
> > If you don't trust decentralized URL-based authentication, this is
> > OpenID's fault but your security policy.
> >
> >   
> 
> 
> I can understand why the Dirk's university does not want to trust
> every identity provider for some specific type of services. There is
> an authorization problem there and the university admin solved it in
> a specific fashion (most likely identities are only created for
> students of that university -- not for every random person on the
> Internet). That's obviously not what the OpenID designers wanted
> since their use cases are somewhat different...

That's what I said, no point in blaming OpenID folks for using it for a
specific purpose.

It's also what some do with XMPP (though not an authentication
protocol).

> In the context of the end-to-end security using XMPP discussion
> luckily many of these things don't really matter.
> 
> You can obviously have cases where an end user does not trust a 
> particular identity provider, does not recognize the authenticated 
> identity as one that is familar to him/her, the authenticated
> identity does not match to any of the identities in the white list
> etc. etc. and hence the entire e2e security procedure fails. But
> that's fine.

OpenID is not for Mandatory Access Control!

The consumer (web application that allows logins) is not expected to
any providers. They are expected to trust the method (using DNS and
HTTP, etc.).

The end user is who chooses his provider.

That's the whole point.

If someone is using OpenID where MAC is required (so the end user is
not allowed to choose his own security policy), decentralized OpenID is
not suitable.

The protocol may be though used with a specific provider but it's no
longer OpenID in its decentralized nature. It's like Jabber without
s2s. The only advantages are existing implementations.

> The main question regarding this mechanism is just whether one would 
> want to trust a third party, in this case the identity provider.

See above.

> From 
> Dirk's previous responses I got the impression that he does not want
> to trust any other party other than the two end points. This use case 
> obviously makes some assumptions but that's his use case.
> The OpenID, the SAML, and the OAuth use cases are different.

The problem with OpenID is not trusting the... provider. It's ok, the
end user has chosen his provider, so without the MAC requirement we're
done.

The REAL problem is trusting the DNS and the TCP/IP network.

> Ciao
> Hannes
> 


-- 

Web: http://www.pavlix.net/
Jabber & Mail: pavlix(at)pavlix.net
OpenID: pavlix.net


More information about the Security mailing list