[OpenID] My answers to the nominee questions

Sun Dec 14 23:17:23 UTC 2008

I think there is a confusion here between confidentiality and authentication.

The association handle is certainly confidential between the OP and
the RP if the connection is over HTTPS. However, the SSL certificate
only authenticates the OP. The OP has at most an IP address to resolve
what party connected and obtained a key. Later, when it receives an
authentication request using that handle, it can perform RP discovery
but that also does not bind to the association handle. So it can never
be confident that the association handle and the corresponding private
key was shared with the stated RP in the request.

This is not an issue for user authentication, because the RP signs the
assertion so that is only valid in the context of the receiver.
However, an authorization to access user's data that is going to be
used later in a server-to-server call by an (again, known to the OP
only by an IP address) entity is a very high risk for the OP to
expose.

BTW, Allen, myself and others are working on a merged (hybrid)
protocol to achieve this. It is mostly based on OpenID but includes a
number of elements from the OAuth protocol. The proposal for this
hybrid protocol is available at wiki.openid.net as a working group.

On Sun, Dec 14, 2008 at 9:06 AM, Peter Williams <pwilliams at rapattoni.com> wrote:
>
>
>> -----Original Message-----
>> From: Breno de Medeiros [mailto:breno at google.com]
>> Sent: Saturday, December 13, 2008 10:36 PM
>> To: Peter Williams
>> Cc: Allen Tom; SitG Admin; general at openid.net
>> Subject: Re: [OpenID] My answers to the nominee questions
>>
>> On Sat, Dec 13, 2008 at 5:33 AM, Peter Williams
>> <pwilliams at rapattoni.com> wrote:
>> > Say more!  given the OP is the deliverer of "the data".
>> >
>> >
>> >
>> > Why not use the AX extension for these querying functions, given the
>> openid
>> > association (over which an OP knows it itself has recently sent an
>> > assertion) is essentially a persistent authorization ticket?
>> >
>> >
>> >
>> > Do we need to reopen the backchannel flow of openid messaging to
>> deliver AX
>> > (and the other openid extensions being normalized)?
>> >
>> >
>> >
>> > Was the openid2 backchannel flow closed, to facilitate OAUTH getting
>> its
>> > spot in the stack (under some Identerati deal)? Should we reopen it?
>> >
>> >
>> >
>> > Architecturally, it seems silly to do adopt OAUTH, if openid would do
>> the
>> > same job using a mere extension.
>>
>> OpenID only authenticates the OP, not the RP. The association provides
>> only a mechanism for the OP to sign statements that the RP can
>> validate. Nothing that the RP can say to the OP will be bound to
>> anything like a realm and is meaningless. Therefore the OP cannot
>> securely grant RP long-term access to user's data at the OP, even with
>> user's consent.
>
> [Peter Williams]
>
> Lets reason from the spec; simply using what it provides. (I'm way too dumb to do anything else, like innovate.)
>
> When needing to talk to the OP to have it verify the signature, the RP cites a private-association key. The OP MUST ensure its using a private association type, furthermore; it MUST NOT use a shared association. If the RP obtains at least one +ve response signature verification from that the OP based on the private_association handle, it has confirmation-grade evidence that the private association key handle is in fact...what it is supposed to be: a private association "key".
>
> In any case, we know the association handle is essentially a [pairwise] key, from the use of the word "key" in 8.2.1
>
> Isn't that value SEMANTICALLY a bilaterally-shared secret (defining the notion of "private" association)?
>
> Doesn't the "association" request/response protocol (that transfers the OP-issued assoc_handle=key, and the optionally-cleartext MAC key) typically leverage confidentiality provided by https, in reality? And doesn't SSL's confidentiality service derive from SSL's peer-entity authentication handshake (for public key ciphersuites), whose MITM properties derive from the classical asymmetric key management (certs!)
>
> I'd assumed that the following was the design intent of openid: Define a security control for OPs to verify symmetric-keyed signatures that rely on private associations; define a handle that embodies the bilateral-privacy feature of the private association; define a req/response protocol for communicating the handle; recommend that folks use https to protect that req/response protocol (which allows one to treat the handle as a [secret] key) that "authorizes" an RP to access the signature verification service.
>
> Given all that, an OpenID RP would already seem to have a bilaterally-shared secret key with the OP: the assoc_handle of a private association. And, its not involved in signature making/verifying processes. Rather it's a security critical value... that control the latter procedure.
>
> Surely 15.1.2 para 2 (guarding against OP spoofing, to address MITM on signature validation) means a decent grade of OP will be requiring SSL on association formation?
>
> Doesn't the final paragraph STRONGLY RECOMMEND (a) use of SSL (b) use of certificates/CTLs to make OP spoofing harder, and (c) SSL must be applied COMPLETELY (in all procedures)?
>
> If we have done ALL THAT, surely we COULD treat the assoc_handle of type private_association to be per-RP password, for the purposes of access control at the OP that issued it?
>
> While today, that value is only applied to authorization controls on signature validation, we seem to have already have something that OAUTH needs.
>
> This sounds like good news, and a strong technical basis for harmonization. OATH messages could have a home as another openid extension (in the openid "stack" of extensions), and existing openid associations already seem to have strong support for the key management that OAUTH might leverage.
>
> Obviously more work required. But, not bad! If there is a will, these 2 COULD merge.
>
>
>> OAuth on the other hand, only authenticates the consumer, but not
>> service provider. So OpenID + OAuth, where OAuth consumer = RP and
>> OAuth SP = OP achieves: (1) authentication user + OP -> RP and (2)
>> authorization RP -> user data at OP.
>>
>> OpenID could have designed a key agreement scheme in the association
>> request to involve a full handshake and output a 2-way authenticated
>> HMAC Key. Then it would be able to support authorization requests.
>> However, simply opening the back-end channel and expecting the OP to
>> send user's data to an unknown site is a non-starter.
>
> [Peter Williams]
>
> The building blocks are all there.
>
> Both OpenID AX client and OATH clients (both at RPs) could benefit from inband client auth - _perhaps_ leveraging what openid auth provides for its own use, similarly for signature validation.
>
> If one argues that OATH client really doesn't want an association with the OP or AX responder (but want to associate with 4thparty data provider), one has the classical KDC option. Since Openid's handshake obviously only sets out to address (one-way) signatures leveraging on symmetric keying (ignoring 25 years of better public key solutions!!), and since the OP is in charge of the association_handles, it can act as a classical symmetric key translator between the RP#1 and other RPs: RP1's data partners (OAUTH "service providers").
>
>
> Not much point going any near here, tho, till there is a demonstration of will to merge. It's not obvious yet folks WANT to, from the fencing language being used.
>
>
>> >
>> >
>> >
>> > (Im pretty ignorant on the topic of OAUTH, but open minded.)
>> >
>> >
>> >
>> > I keep waiting for the RDF crowd to define an openid extension that
>> is
>> > a(nother) binding for SPARQL queries, leveraging the authorization
>> functions
>> > of the openid association keys and assoc-identifiers to do I&A and
>> machine
>> > authz - much as folks use SSL session-keys and session-identifiers.
>> >
>> >
>> >
>> > From: general-bounces at openid.net [mailto:general-bounces at openid.net]
>> On
>> > Behalf Of Allen Tom
>> > Sent: Friday, December 12, 2008 6:48 PM
>> > To: SitG Admin; general at openid.net
>> > Subject: Re: [OpenID] My answers to the nominee questions
>> >
>> >
>> >
>> > SitG Admin wrote:
>> >
>> >
>> >
>> > It would be nice if RP's had a "I'll scratch your back if you'll
>> scratch
>> > mine." system by which they could send short messages to one
>> another's
>> > networks - for instance, Monster.com would say "Hey Yahoo, please
>> notify all
>> > the Friends of this user on your network, blah blah blah." and Yahoo
>> could
>> > do so.
>> >
>> > Yahoo has an OAuth protected API that allows a Yahoo user to
>> authorize an RP
>> > to write to the user's Activity Stream using the Yahoo! Updates API.
>> The
>> > user's connections would be able to see the message in their Updates
>> feed.
>> > This is very similar in concept to the News Feed on other sites.
>> >
>> > It would be really nice if a user could sign into an RP using OpenID,
>> and
>> > simultaneously authorize that site to access their data on Yahoo
>> using
>> > OAuth. Expect to hear more about this soon.
>> >
>> > More info about the Yahoo! Updates API is here:
>> > http://developer.yahoo.com/social/updates/
>> >
>> > Allen
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > general mailing list
>> > general at openid.net
>> > http://openid.net/mailman/listinfo/general
>> >
>> >
>>
>>
>>
>> --
>> --Breno
>>
>> +1 (650) 214-1007 desk
>> +1 (408) 212-0135 (Grand Central)
>> MTV-41-3 : 383-A
>> PST (GMT-8) / PDT(GMT-7)
>

-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)