[Openid-specs-mobile-profile] Interlock Solutions

Torsten Lodderstedt torsten at lodderstedt.net
Tue Mar 31 06:06:15 UTC 2015


Hi Nat,

just to make sure I understand you right:

 "app" refers to an authentication app, which actually performs the OOB authentication. The request_uri of the authentication request from the SP/RP is directly relayed by the IDP to this app. The app in turn obtains consent (and probably uses additional authenticators as well) and sends the result back to the IDP.

So in my interpretation, you are proposing two things:
- the RP shall use request uri to securely pass the parameters to the IDP
- a way to implement the interaction between IDP and authentication app (via request uri)

Correct?

What I don't understand is, how the app is able the verify the request uris signature. Does the IDP provide the app with the SPs public key?

best regards, 
Torsten. 

Am 30. März 2015 20:29:47 MESZ, schrieb Nat Sakimura <sakimura at gmail.com>:
>FYI, I have an implementation that does more-or-less of the following:
>
>(1) The app registers itself to the IdP, with self-generated key-pair's
>public key.
>(2) The SP sends request_uri
>(3) The app gets the request object from request_uri
>(4) The app checks the signature, and displays it to the user: how much
>this transaction involves to whome etc.
>(5) User taps accept button.
>(6) The app counter signs the request object with the private key and
>sends
>the response back to the IdP.
>(7) IdP verifies the signature of the response, and determines whether
>to
>go forward with the transaction.
>
>FYI, this is basically what was once called Contract Exchange (CX),
>which
>is a dormant Working Group in OIDF that started in 2008. Artefact
>Binding/Connect WG started off from there -- we wanted to build CX but
>did
>not have suitable tools. So, in 2009, John, Breno, and I started a new
>working group that builds the tools that was needed for CX: The AB WG.
>There after, we have built:
>- A signature mechanism: JWS -- was JSON Simple Sign.
>- An encryption mechanism: JWE -- was JSON Simple Encryption.
>- (and algorithms -- JWA, which was later further separted.)
>- A Token format: JWT
>- A basic communication protocol: OAuth 2.0
>- An identity layer that is built on all the above: OpenID Connect 1.0
>Suite
>
>And finally, we are able to build CX, which should be a pretty small
>spec
>now.
>
>I was talking with John last Thursday about this, whether we should
>revive
>CX, or do it in Mobile WG.
>Our conclusion was that since Mobile WG has a similar scope in it, and
>it
>probably is a much hassle for MNOs to sign another agreement, it would
>be
>better to do it here. (but that's only one opinion.)
>
>Cheers,
>
>Nat Sakimura
>
>
>2015-03-25 23:31 GMT+09:00 John Bradley <ve7jtb at ve7jtb.com>:
>
>> No not all clients have a client secret.   As an example almost no
>native
>> apps have them.
>>
>> Connect allows a asymmetrically signed assertion to be used to
>> authenticate a client.
>>
>> That is set up as part of registration and no client secret is
>returned.
>>
>> One option might be that the software statement might contain the
>clients
>> public key for authentication.  That would allow a client to have one
>key
>> pair in a HSM that could be used across all IDP as an example.
>>
>> Sent from my iPhone
>>
>> On Mar 25, 2015, at 8:57 AM, GONZALO FERNANDEZ RODRIGUEZ <
>> gonzalo.fernandezrodriguez at telefonica.com> wrote:
>>
>> Hi John,
>>
>>  I have been reviewing the Request Object and it sounds good. However
>I
>> don’t understand why you says that not all the clients will have a
>> symmetric key, everyone has a client_id, client_secret, hasn’t?
>>
>>  Regarding your proposal about extending the mechanism to digitally
>sign
>> a text, how the digital signed would be returned to the Service
>Provider?
>>
>>  Best,
>> Gonza.
>>
>>
>>   From: John Bradley <ve7jtb at ve7jtb.com>
>> Date: Wednesday 25 March 2015 13:19
>> To: Gonzalo Fernández <gonzalo.fernandezrodriguez at telefonica.com>
>> Cc: "openid-specs-mobile-profile at lists.openid.net" <
>> openid-specs-mobile-profile at lists.openid.net>
>> Subject: Re: [Openid-specs-mobile-profile] Interlock Solutions
>>
>>   Connect has a way to send an encrypted/signed request.
>>
>>  Using the request object we would just need to define an additional
>> claim to carry the information.
>>
>>  I don’t think that we need to have anything else special, there is
>> all-ready a way in connect to establish encryption keys.
>>
>>  Not all clients will have a symmetric key is the other point.  I
>think
>> we are still debating making the client authentication asymmetric to
>reduce
>> key management overhead in the clients and servers.
>>
>>  In any event I think we are better of sticking to the defined method
>of
>> encrypting requests.
>>
>>  We would do the same sort of extension to allow a client to pass in
>text
>> to be digitally signed.  I know that is an extesion some peole will
>also
>> want in cases where the MNO can proxy a qualified digital signature.
>>
>>  John B.
>>
>>  On Mar 12, 2015, at 6:47 AM, GONZALO FERNANDEZ RODRIGUEZ <
>> gonzalo.fernandezrodriguez at telefonica.com> wrote:
>>
>>  Hi Guys,
>>
>>  As I promised yesterday, find below the concern raised in our call
>> yesterday. As you know Torsten has opened a ticket here:
>>
>http://hg.openid.net/mobile/issue/1/service-provider-wants-to-influence.
>>
>>  @Torsten, the idea is discuss it using the tool or by email?, anyway
>as
>> I don't have access as a writer, by the moment I use the email :-)
>>
>>
>>
>>  First of all, I want to highlight that this problem mainly affects
>to
>> the use cases where Mobile Connect is used as a second factor of
>> authentication, what is probably closer to an authorization than an
>> authentication.
>>
>>  Some banks are really concerned about the interlock between the
>> authentication device, that is the mobile where the user receive the
>> challenge to ask him for the credentials (e.g: PIN Code in SIM applet
>> authenticator) and the consumption device, that is the provider's web
>site
>> (in this case the bank website) where the user is doing some
>transactions.
>>
>>  We already have in Mobile Connect a solution to solve this interlock
>and
>> be able to correlate the authentication and the consumption device,
>this
>> solution is based on generate a One Time Code in the ID_GW (OpenID
>Connect
>> Server) and show it in both devices. However the banks would like an
>step
>> further and be able to have influence in the text that is showed to
>the
>> users to ask for the authentication, in that way the can provide any
>data
>> they want that is related just with the current transaction that user
>is
>> asking for (e.g: four last digit of the destination account in a
>money
>> transfer).
>>
>>  My proposal is to add a query parameter in the authentication
>request to
>> allow the Service Provider to provide the final message to the user,
>of
>> course the OIDC Server wouldn't check any information (like amounts
>in a
>> transfer or whatever). The Service Provider would have the
>responsibility
>> to generate the proper message and the OIDC Server should truncate
>the
>> message in case of having a length over a maximum length defined.
>Regarding
>> the security this message must be encrypted because it could have
>sensitive
>> information and my proposal would be to use the client_secret if it
>is
>> possible and encrypt an sign using AES.
>>
>>  The summary of the solutions for the interlock would be the next,
>from
>> my point of view 1 should be applied in case 2 is not present.
>>
>>  Two solutions to solve the interlock problem
>>
>>  1. INTERNAL TRANSACTION_ID GENERATION
>>
>>    - Generate a number in the AuthServer that identifies the
>transaction.
>>    Show this number in both devices: authentication and consuption.
>>    - Pros: SPs don't need to do additional developments.
>>    - Cons: Not possible to add any semantic value that refers to a
>value
>>    of the transaction in the Service Provider web site (like an
>amoutn, etc)
>>
>>
>>  2. ADDING QUERY PARAMETER
>>
>>    - Additional query parameter to allow the SP to customize the
>message.
>>    - Pros: allow to the SP to set any message containing any value it
>>    wants, improving security and probably the UX.
>>    - Cons:  in order to allow a secure solution, this query parameter
>>    should be encrypted and sign.
>>
>>  Best,
>> Gonza.
>>
>> ------------------------------
>>
>> Este mensaje y sus adjuntos se dirigen exclusivamente a su
>destinatario,
>> puede contener información privilegiada o confidencial y es para uso
>> exclusivo de la persona o entidad de destino. Si no es usted. el
>> destinatario indicado, queda notificado de que la lectura,
>utilización,
>> divulgación y/o copia sin autorización puede estar prohibida en
>virtud de
>> la legislación vigente. Si ha recibido este mensaje por error, le
>rogamos
>> que nos lo comunique inmediatamente por esta misma vía y proceda a su
>> destrucción.
>>
>> The information contained in this transmission is privileged and
>> confidential information intended only for the use of the individual
>or
>> entity named above. If the reader of this message is not the intended
>> recipient, you are hereby notified that any dissemination,
>distribution or
>> copying of this communication is strictly prohibited. If you have
>received
>> this transmission in error, do not read it. Please immediately reply
>to the
>> sender that you have received this communication in error and then
>delete
>> it.
>>
>> Esta mensagem e seus anexos se dirigem exclusivamente ao seu
>destinatário,
>> pode conter informação privilegiada ou confidencial e é para uso
>exclusivo
>> da pessoa ou entidade de destino. Se não é vossa senhoria o
>destinatário
>> indicado, fica notificado de que a leitura, utilização, divulgação
>e/ou
>> cópia sem autorização pode estar proibida em virtude da legislação
>vigente.
>> Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique
>> imediatamente por esta mesma via e proceda a sua destruição
>>  _______________________________________________
>> Openid-specs-mobile-profile mailing list
>> Openid-specs-mobile-profile at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile
>>
>>
>>
>> ------------------------------
>>
>> Este mensaje y sus adjuntos se dirigen exclusivamente a su
>destinatario,
>> puede contener información privilegiada o confidencial y es para uso
>> exclusivo de la persona o entidad de destino. Si no es usted. el
>> destinatario indicado, queda notificado de que la lectura,
>utilización,
>> divulgación y/o copia sin autorización puede estar prohibida en
>virtud de
>> la legislación vigente. Si ha recibido este mensaje por error, le
>rogamos
>> que nos lo comunique inmediatamente por esta misma vía y proceda a su
>> destrucción.
>>
>> The information contained in this transmission is privileged and
>> confidential information intended only for the use of the individual
>or
>> entity named above. If the reader of this message is not the intended
>> recipient, you are hereby notified that any dissemination,
>distribution or
>> copying of this communication is strictly prohibited. If you have
>received
>> this transmission in error, do not read it. Please immediately reply
>to the
>> sender that you have received this communication in error and then
>delete
>> it.
>>
>> Esta mensagem e seus anexos se dirigem exclusivamente ao seu
>destinatário,
>> pode conter informação privilegiada ou confidencial e é para uso
>exclusivo
>> da pessoa ou entidade de destino. Se não é vossa senhoria o
>destinatário
>> indicado, fica notificado de que a leitura, utilização, divulgação
>e/ou
>> cópia sem autorização pode estar proibida em virtude da legislação
>vigente.
>> Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique
>> imediatamente por esta mesma via e proceda a sua destruição
>>
>>
>> _______________________________________________
>> Openid-specs-mobile-profile mailing list
>> Openid-specs-mobile-profile at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile
>>
>>
>
>
>-- 
>Nat Sakimura (=nat)
>Chairman, OpenID Foundation
>http://nat.sakimura.org/
>@_nat_en
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Openid-specs-mobile-profile mailing list
>Openid-specs-mobile-profile at lists.openid.net
>http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20150331/f2a74528/attachment-0001.html>


More information about the Openid-specs-mobile-profile mailing list