[Openid-specs-mobile-profile] CIBA Issues Review: Feedback for #62

Petteri Stenius Petteri.Stenius at ubisecure.com
Mon Mar 12 12:52:11 UTC 2018


Hi Nicholas

That is correct, the code will become known to all applications using back channel flows where I have logged on.
Do you think there is a risk of the applications collecting the code and using the code for sending unsolicited authentication requests? Is the situation any worse than it is without user code?
What we want to do is prevent anybody who only needs to know my phone number from sending unsolicited authentication requests.

About OTP: My authentication device could generate and display the OTP in the device’s user interface.

Regards,
Petteri


From: nicolas.aillery at orange.com <nicolas.aillery at orange.com>
Sent: maanantai 12. maaliskuuta 2018 14.28
To: Petteri Stenius <Petteri.Stenius at ubisecure.com>
Cc: openid-specs-mobile-profile at lists.openid.net; PABLO GUIJARRO ENRIQUEZ <pablo.guijarroenriquez at telefonica.com>; GONZALO FERNANDEZ RODRIGUEZ <gonzalo.fernandezrodriguez at telefonica.com>
Subject: RE: CIBA Issues Review: Feedback for #62

Hello Petteri,

   In the case you describe, the secret is not secret anymore (shared amongst all apps).
   How would you implement an OTP-like antispam code?

Regards,
Nicolas

De : Petteri Stenius [mailto:Petteri.Stenius at ubisecure.com]
Envoyé : lundi 12 mars 2018 12:52
À : AILLERY Nicolas IMT/OLS
Cc : openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>; PABLO GUIJARRO ENRIQUEZ; GONZALO FERNANDEZ RODRIGUEZ
Objet : RE: CIBA Issues Review: Feedback for #62

Hi Nicholas,

I am not trying to reproduce an oauth 2 use case with user code.

Let me clarify with an example

Registration


1.      I register for Mobile PKI service at my mobile operator

2.      I register a spam prevention code by sending a PIN code by SMS to my mobile operator

Logon


1.      To logon to an application with Mobile PKI, I enter my mobile phone number on a logon form

2.      The application attempts to send authentication request to my mobile phone but receives an error code indicating spam prevention code is required

3.      The application presents a form for entering the spam prevention code

4.      I enter the PIN I registered

5.      Application is allowed to send authentication request to my mobile phone


Regards,
Petteri


From: nicolas.aillery at orange.com<mailto:nicolas.aillery at orange.com> <nicolas.aillery at orange.com<mailto:nicolas.aillery at orange.com>>
Sent: maanantai 12. maaliskuuta 2018 12.53
To: Petteri Stenius <Petteri.Stenius at ubisecure.com<mailto:Petteri.Stenius at ubisecure.com>>; GONZALO FERNANDEZ RODRIGUEZ <gonzalo.fernandezrodriguez at telefonica.com<mailto:gonzalo.fernandezrodriguez at telefonica.com>>
Cc: openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>; PABLO GUIJARRO ENRIQUEZ <pablo.guijarroenriquez at telefonica.com<mailto:pablo.guijarroenriquez at telefonica.com>>
Subject: RE: CIBA Issues Review: Feedback for #62

Hello Petteri,

   If the « user_code » is a way to materialize the fact that the user allowed a SP to use CIBA, I think we are very close to an OAuth2.0 use case, the user_code being an access_token. This situation looks like a nonsense for me.
   It seems important to have a clear view of the use cases where the user_code is involved to address them the best way,

Regards,

Nicolas

De : Petteri Stenius [mailto:Petteri.Stenius at ubisecure.com]
Envoyé : lundi 12 mars 2018 10:48
À : GONZALO FERNANDEZ RODRIGUEZ; AILLERY Nicolas IMT/OLS
Cc : openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>; PABLO GUIJARRO ENRIQUEZ
Objet : RE: CIBA Issues Review: Feedback for #62

Hello,

I have written a proposal for this feature into issue tracker https://bitbucket.org/openid/mobile/issues/62/ciba-support-for-spam-prevention-code-in

My proposal for name of parameter is user_code. The code is used to authorize sending an authentication request to user’s authentication device. In other words to prevent unsolicited authentication requests from appearing on user’s authentication device.

I completely agree that there are many cases where this mechanism is not required. Still it is quite easy to identify cases where it may be necessary. That is why the parameter is optional.

The details of how user codes works and are registered is not within the scope of this proposal. However it is perfectly possible to implement user codes as one time passwords. For example, to authorize an authentication request you’d enter a one time code that is shown on the authentication device.

Petteri

From: Openid-specs-mobile-profile <openid-specs-mobile-profile-bounces at lists.openid.net<mailto:openid-specs-mobile-profile-bounces at lists.openid.net>> On Behalf Of GONZALO FERNANDEZ RODRIGUEZ
Sent: lauantai 10. maaliskuuta 2018 14.49
To: nicolas.aillery at orange.com<mailto:nicolas.aillery at orange.com>
Cc: openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>; PABLO GUIJARRO ENRIQUEZ <pablo.guijarroenriquez at telefonica.com<mailto:pablo.guijarroenriquez at telefonica.com>>
Subject: Re: [Openid-specs-mobile-profile] CIBA Issues Review: Feedback for #62

Hi Nicolas,

First of all, thank you for your feedback.

I understand your view, I personally don't like to use an anti-spam code in CIBA, however it is only a proposal that try to fullfil the requirements of this opened issue, and if the WG don't agree we can decide not include the anti-spam code :).  However I have to say that in spite of the fact that I agree that a secret among more than 2 people is not a secret, what is proposed to be included in the CIBA spec in a way to carry-out the anti-spam code in the protocol and the way that it is shared is out of the scope of this spec.

The OpenID providers can offer a secure way to share the anti-spam code with the Service Providers asking the user for consent (of course). I personally don't see the utility of it, I only can think about it as a way where a user could have potentially more control on what he wants to allow to Service Providers, that is, those who has the anti-spam code could interact with the user using the CIBA flow, otherwise they must use the Device flow.

Honestly I don't think these use cases makes sense, we don't have these kind of use cases reported by Petteri and we really think that a Service Provider shouldn't have any interest in doing spam and others couldn't do it because CIBA authentication request uses an authenticated endpoint and only Service Providers can use it, but it was the only way I thought it could be supported by the protocol.

P.D: agree that “spam-code” can be confusing ☺

Best,
Gonza.

From: "nicolas.aillery at orange.com<mailto:nicolas.aillery at orange.com>" <nicolas.aillery at orange.com<mailto:nicolas.aillery at orange.com>>
Date: Friday, 9 March 2018 at 10:30
To: GONZALO FERNANDEZ RODRIGUEZ <gonzalo.fernandezrodriguez at telefonica.com<mailto:gonzalo.fernandezrodriguez at telefonica.com>>
Cc: PABLO GUIJARRO ENRIQUEZ <pablo.guijarroenriquez at telefonica.com<mailto:pablo.guijarroenriquez at telefonica.com>>, "openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>" <openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>>
Subject: RE: CIBA Issues Review: Feedback for #62

Hello Gonzalo,

   Here are two remarks about your proposal :

-       I think using the wording ‘spam-code’ to describe an *anti*spam code will introduce some confusion.

-       I’m not sure it’s a good idea to expose the antispam code on CIBA. This code is similar to a user password, so it should be a secret between a user and his MNO. It was created to protect the user in a situation where anybody was able to enter any MSISDN on a public form (e.g. the GSMA discovery page before an OpenId Connect interaction). In CIBA, it’s the SP that will call CIBA, so using an antispam code implies that the secret is also shared amongst all SP (is this still a secret?). On another hand, is there still a spam risk in CIBA? Yes, if SP allow any user to enter any MSISDN, but in this situation the SP should use the classic OpenId Connect flow (because the user is already using the SP to be able to enter a MSISDN). No, if the SP uses CIBA as a second factor. My proposal is that CIBA does not implement antispam code, and that MNO does not check the antispam code when CIBA is used.

   What is your point of view about this proposal?

Best regards,
Nicolas

De : Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-bounces at lists.openid.net] De la part de GONZALO FERNANDEZ RODRIGUEZ
Envoyé : vendredi 2 mars 2018 14:40
À : openid-specs-mobile-profile at lists.openid.net<mailto:openid-specs-mobile-profile at lists.openid.net>
Cc : PABLO GUIJARRO ENRIQUEZ
Objet : [Openid-specs-mobile-profile] CIBA Issues Review: Feedback for #62

Hi all,

I continue asking you for feedback about another CIBA issue, in that cases is the #62 https://bitbucket.org/openid/mobile/issues/62/ciba-support-for-spam-prevention-code-in

The spam-code belongs to the end-user, so it should be configured by the end-user in the OpenID Provider.
The CIBA flow doesn't have an interactive session with the end-user, but is the user who is contacted directly in his authentication device, what means that the end-user won't have the possibility to introduce the spam-code in his authentication, so, it only could be done by the Client.

We think that it would be possible to add support for that in CIBA as follow:

1.            A new OPTIONAL field "spam-code" in the CIBA authentication request.
2.            An specific error in case of the end-user had the anti-spam activatedin the OIDC and the Service Provider didn't include it in the authentication request.

It is worth it to highlight that this would be an optional feature implemented by the OIDC's and it should be "out of the scope" of CIBA to define how the end-user would share the spam-code with the Service Provider and how the end-user would configure the spam-code in the OIDC.

I would like to know again your point of view on that in order to resolve this issue.

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

_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

________________________________

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

_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20180312/e5cdde47/attachment-0001.html>


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